Provide Translations for Standard Glyph Names and Tables

[magasek]

Problem Statement:

With the vast number of glyphs available in SMuFL fonts, users need a method to easily find what they need. The Glyph Tables help with grouping like items, but users often still need search functionality. The problem is that all the standard glyph and table names are in English. While the group names can be readily translated, search mechanisms can only be done using those English names. In addition, if translations don't match from product to product, users might be confused if they have to use more than one. As a developer of internationally sold notation software, I want my users to have correct and consistent names for SMuFL items in their own language so they can be delighted with the ease in which they can use SMuFL in my software.

Proposal:

Provide a standard list of translated names for glyph tables and glyph names in the SMuFL specification so all notation products can provide consistent naming for their users, and so users can search for glyphs in their own language. We could ask for creators of notation products to obtain permission from translation partners to volunteer translations that they have already received and/or request additional ones for inclusion in the spec.

[Jojo-Schmitz]

In MuseScore we are translating those, at least the ones we actually use. See e.g. https://www.transifex.com/musescore/musescore/translate/#de/$/157996539?q=context%3AsymUserNames for the German translations

[rettinghaus]

Something like glyphnames.json with multiple languages would be nice.

[Jojo-Schmitz]

glyphnames-de.json, glyphnames-nl.json, ...

[dspreadbury]

Perhaps we could consider setting up a project on Transifex for this, if SMuFL qualifies as a sufficiently open source project for their "forever free" plan.

[dspreadbury]

I've spent a bit of time this morning speculatively setting up a Transifex project for localising the glyph names and range names metadata:

www.transifex.com/w3c-music-notation-community-group/smufl/

I've simply uploaded the current glyphnames.json and ranges.json metadata files, first changing the name of the description key to message as this is the Chrome i18n JSON format. This is enough to get us started if there are any community members out there who would be interested in helping us with translations.

We will need to decide how to add the localised strings to the metadata files in due course. Probably something like this will be sufficient, e.g. for glyphnames.json:

{
    "4stringTabClef": {
        "codepoint": "U+E06E",
        "description": [
            "en": "4-string tab clef",
            "es": "Clave de tablatura de 4 cuerdas",
            "de": "TAB-Schlüssel (4 Saiten)",
            "fr": "Clef de tablature à 4 cordes",
            "ja": "4 弦タブ記号"
        ],
    }
}

[Jojo-Schmitz]

In MuseScore we do have translations for those glyphs we actively use (as "first class citizen"), and can provide those.

(Edit: I mentioned that above already, sorry for duplication)

[dspreadbury]

At the suggestion of @adrianholovaty, I've also imported the glyphnames.json and ranges.json data into POEditor, another translation platform that he personally uses for Soundslice. It would be interesting to know whether any community members know of any reason why we should prefer either POEditor or Transifex.

https://poeditor.com/join/project/sTLAGH135U

[Jojo-Schmitz]

As MuseScore uses Transifex, I'd personally prefer that over a new (to me) tool

I did request team meambership for the German translation team on Transifex yesterday, but havn't gotten it until now?

[dspreadbury]

Apologies, @Jojo-Schmitz, I don't seem to have had a notification from Transifex of your request, but I've now approved you to join the team.

[rettinghaus]

Funny thing. I wanted to join Transiflex team, but German is not an option any longer, so @Jojo-Schmitz is on his own there.

[dspreadbury]

If you let me know your Transifex username, I can invite you to the German team, Klaus.

[rettinghaus]

Thanks. I'm a bit lost, because my Transiflex Profile page states that I already requested to join the German language team.

[dspreadbury]

Aha, again, there was a pending request that Transifex didn't bother to notify me about. You should now be part of the German team.

[dspreadbury]

@Jojo-Schmitz and @rettinghaus, unless I'm mistaken, it doesn't appear that either of you are yet members of the W3C Music Notation Community Group. In order for any translations that you provide to be used in the SMuFL project, you need to sign up to the group so that you abide by the terms of the W3C Contributor License Agreement.

Please sign up, either on your own behalf but preferably on behalf of the organisation you represent (particularly if you, @Jojo-Schmitz, will be contributing translations from MuseScore), so that we can be sure everything is above board.

This is my fault: I shouldn't have accepted you onto the team at Transifex without first verifying that you are members of the CG.

To sign up, please go to the main page on the W3C Communities site and click Join this group.

[Jojo-Schmitz]

I just did (I think)

[dspreadbury]

I'd like to get the opinion of the community about the different possible approaches we could take to handling the localised names for glyphs and ranges. As I see it, we have at least four options:

1. Embed the localised strings in the existing JSON files (e.g. make "Description" an object with one key/value per language, or if we prefer for backwards compatibility, add a new object alongside "Description" that only contains the localised strings as key/value pairs).
2. Duplicate the existing JSON files in each language (e.g. have ranges_de.json, where "Description" contains only the German name).
3. Create a parallel JSON file containing only the translations (e.g. have ranges_names.json, which contains only the localised "Description" values, keyed off the range name/identifier).
4. Externalise the strings altogether using something like a gettext PO file (e.g. one PO file per metadata file, per language, something like ranges_de.po, where msgid uses the English-language "Description" values and msgstr is the localised German string).

My preference is for option 1, since it is the smallest change in terms of the overall deliverables as part of the SMuFL specification, and this would pose no implementation difficulties for us in Dorico. But what do other developers think?

[magasek]

Daniel,

Strictly looking from a structural view, I would prefer option 1. But I am concerned with option 1's performance. The current English-only glyphnames.json is around 300KB. Add just 7 more languages to that (as Finale supports) and we're up to over 2.5MB. That will affect loading and parsing performance.

Option 2 would be better for performance. Even given the potential need to fallback to a different language if a string isn't available, we need only parse 2-3 languages and not all 8 or more.

Of course, developers can create scripts to convert between the options as their particular needs dictate. The real value is to have the translations at all.

On Wed, Sep 14, 2022 at 7:38 AM Daniel Spreadbury @.***> wrote:

I'd like to get the opinion of the community about the different possible approaches we could take to handling the localised names for glyphs and ranges. As I see it, we have at least four options:

1. Embed the localised strings in the existing JSON files (e.g. make "Description" an object with one key/value per language, or if we prefer for backwards compatibility, add a new object alongside "Description" that only contains the localised strings as key/value pairs).
2. Duplicate the existing JSON files in each language (e.g. have ranges_de.json, where "Description" contains only the German name).
3. Create a parallel JSON file containing only the translations (e.g. have ranges_names.json, which contains only the localised "Description" values, keyed off the range name/identifier).
4. Externalise the strings altogether using something like a gettext PO file (e.g. one PO file per metadata file, per language, something like ranges_de.po, where msgid uses the English-language "Description" values and msgstr is the localised German string).

My preference is for option 1, since it is the smallest change in terms of the overall deliverables as part of the SMuFL specification, and this would pose no implementation difficulties for us in Dorico. But what do other developers think?

— Reply to this email directly, view it on GitHub https://github.com/w3c/smufl/issues/214#issuecomment-1246779486, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6H7XIIC2YVUAW743PDFX3V6HINJANCNFSM5NNOGENA . You are receiving this because you authored the thread.Message ID: @.***>