Remove hard coded English-only semi-localization from language names #35
Conversation
|
Thanks for thinking about this one. I'm all for localizing more elements, but I don't want to remove the feature altogether without building a fallback. The group that uses this the most - the Digital Bible Society - often wants English fallbacks since that its the common language for so many partner translators and distributors. For the language dropdownlist, I think it would be pretty easy to enable localization support (name: English, name_de: 'Englisch', name_tr: 'ingilizce', es: 'Inglés' ... ). However, I have no idea if many Bible translation names have been translated into other languages. The 'nameEnglish' field might be better as nameAlternate or something like that to be more of a fallback alternate. Right now it's not being used heavily by the team creating inscript.org, but I'll check with them on what they think. So for now, I'll hold of on this until we can have a more robust fallback system. |
|
My commit messages and PR copy might have confused the issue here a but, but I think it's worth clarifying. What you responded to is, in my mind, a separate issue from what I was proposing here. You might have noticed that in addition to the branch this PR is based on (localization-languages) I also have another branch (localization-translations) that I did not submit a PR for. It is based on this PR but extends it a lot farther than I thought no have included upstream just yet. The logic behind that is that your comment about needing a "robust fall-back system" makes sense to me for the translation selection menu. Even though I've preferred the stripped down version for my install I didn't think it was worth suggesting the removal of functionality from the upstream branch. Instead of gutting it, this should probably be replaced by a full matrix of localized language names. Piggy backing on that, each translation meta data file should include as many localized names as possible. On the other hand the interface language selector itself does not need fall-backs. The fact that there is a menu and each language is localized in the menu is the fall-back. That's how you pick the fall-back language you want to use the site in. If English is the language some "partner translator or distributor" wants to use, it is available in the menu as "English" no matter what the default localization is. That's the fall-back they need get the site into the common language they know. Selecting it makes all the features of the site (and per above, potentially even language name and translation labels in the translation selector) to be localized in a language the user knows . You don't need the other language names to be localized because using the localized interface won't make any sense outside the context of knowing the language. |
Having this string is un-necessary in the case of the default English UI (if you don't recognize the name of the language, content in that language is not going to be very useful to you) and outright dead-weight in the context of a localized UI (if you are using a not-English version, non-localized strings hard coded in English are not that useful). Unless we include a full language name matrix with each language name localized in each of the languages the site can be localized, it is more generally useful to just show languages using their localized names (not to mention easier). Looking around at major platforms with localization support, this appears to be the norm now (as opposed to a few years ago when localization was first rolling out to a few programs and was being driven by and English-first mindset). If anything needs a hard-code English fall-back for people to "escape" from a language they do not understand it would be the name of the setting and the widget itself. Once they find the widget, having "English" as a value in the list is enough.
|
I'll be off for about the next two week so I'll take a look when I get back. In the mean time if there are any features you're thinking of working on let me know.
|
It might be better to do this in much the same way as countries are handled. Have a single element (name_i18n) with an array of language > values. name_i18n: ['de': 'Englisch', 'tr': 'ingilizce', 'es', 'Inglés', ...] In fact, all fields could have an _i18n equivalent that works the exact same way. Short names, long names, descriptions. Anything. If a "global" internationalization setting is enabled, it reads from the _i18n fields with a fallback to the standard fields. |
In the process of trying to get a completely localized interface (see also #33 and #32), one thing that was sticking out was the hard coded English strings attached to language names. As explained in the commit message for 4a53bc6, I believe these to be unnecessary and cumbersome.
I would suggest ditching them entirely in favor of just using localized language names. People are going to know where to find and how to read the languages that are of interest to them. Non English speakers are actually going to recognize more of the localized names than they will the EN names.
The only exception that comes to mind is not important for the language selector menu so much as for the names of translations. Namely for Greek and Hebrew I know there are some users with an interest in texts in those languages that don't actually know beans about them. Whether these are the sort of users you want to cater to or not is something I would question¹, but let's assume for now you do. These are a strange beast anyway as the content modules are often catered to an English audience even though the content may be in Greek or Hebrew. The GWH module for example has English delimiters inline in the Greek text.
In any event the current module names are in English anyway, so for now the English usage isn't broken and localizing translation names is something I'll be playing with in my localization-languages branch and save for a later PR when it gets sorted out.
¹ If they can't find «עִבְרִית» in a menu how useful is it going to be for them to start readingבְּרֵאשִׁ֖ית בָּרָ֣א» אֱלֹהִ֑ים אֵ֥ת הַשָּׁמַ֖יִם וְאֵ֥ת הָאָֽרֶץ׃»?