i18n/l10n of Elvish's builtin messages

[xiaq]

Maybe Elvish's messages should be translatable.

[krader1961]

Why the "maybe" label? This is definitely a low priority but any modern shell should make basic accommodations to the user's locale. Including error messages in the user's locale if those translations are available. In issue #1004 I wasn't proposing that Elvish provide translations of its message to any specific language. Only that the implementation should make it possible to do so. Then people who can read/write English and a second language can contribute message translations.

I've lived most of my life in the USA but did spend 19 months working in the Asia-Pacific region. Including Malaysia, China, South Korea, Japan, etc. While it would be nice if everyone spoke, and could read, a common language (e.g., English) that isn't going to happen anytime soon. Certainly not in my lifetime. Not even in the IT industry. While widely used legacy shells such as ksh don't have localized messages bash does have such support. Elvish should have parity with bash with respect to this issue.

[xiaq]

Most of Elvish's messages are error messages or otherwise highly technical messages. Localization of technical messages is easy to get wrong and hard to get right:

• It is hard to quality-control the translations. Low-quality localized messages might as well be worse than the original message in English.

  We can rely on community for quality control. For each translation, Elvish needs to have, at the minimum, > 1 users other than the translators themselves who regular used the localized version. That won't be the case for many languages, for a long time.

• Even high-quality translations may not be desirable for two reasons:

  • Shell is a relatively small niche, which means that not all languages have standardized translations for the English terms. Even if a user normally prefers $language over English, they may still find technical English easier to understand than technical $language.

  • Localized error messages are harder to search.

  I normally prefer Chinese in GUI (not only is it easier for me to read, Chinese texts are much more dense and save screen space). But for CLI applications I find Chinese messages to be counter-productive exactly for these reasons, and always prefer seeing the original English messages.

As good as the intention is to localize messages is (thanks BTW :), the decision must ultimately be based on the reality of what people actually need. I have described my situation but obviously different people have different needs.

I am also unashamedly optimizing Elvish for long-term users, so if the translation is better for attracting new users but worse for keeping existing users, that still adds up to net negative for me (unless the upside greatly outweighs the downside, of course).

To all Elvish users who do not speak English as their mother tongue: what's your opinion?

[xiaq]

FWIW, this issue is for the localization of messages that are built into Elvish. Enabling Elvish scripts to output localized messages is out of scope of this issue and tracked separately in #1034.

[zzamboni]

My $.02: My mother tongue is Spanish, but I never use Spanish localization for anything, precisely for the reasons @xiaq noted above: localizations are often low-quality, and most of the documentation you find is in English anyway. Trying to follow English documentation and mapping it to (for example) GUI elements in a different language is excruciating. So I personally use all my GUIs and systems in English.

I agree with your sentiment that shell users are probably less inclined to expect localizations due to the technicality of the messages.

[xiaq]

People who don't speak English as their mother tongue: feel free to vote on this comment, based purely on your personal need, and assuming a reasonably high-quality translation:

• 👍 yes translation please (even if other people may not want it)
• 👎 no I don't want translation (even if other people may want it)

[jiujieti]

I am definitely not the biggest fan of localizing error messages. Based on the narrow community that a shell would have, the situation where all non-native English speakers will still reach out to the wider, English speaking community for help addressing issues, is quite predicable.

[vuryleo]

If there should be one “translation” for Elvish it must be Elvish first.

For shell users (cli users) I would say if the error text is easier to fix by themselves, like missing param X, it’s OK or better to be displayed in native language.

However, even in this case it’s not that harmful to display the message in English. Hey, you are using shell, at least.

But if some tech issue that user may have no idea, it’s better to be displayed in a standard way. Either an English sentence or a so called “error code”. It’s much easier to search with the standard error message other than “localized error message”.

In all, considering the background of Elvish, it won’t be that useful to have translated messages. It may be more helpful if you can learn the “Elvish” while using this shell.

[xofyarg]

Presuming most of the builtin messages under discussion are error messages, I'd vote for enumerating them and give the opportunity to users. It will not only help spreading Elvish, but also make error prediction easier, e.g. for writing tests, building webui. i18n/l10n is definitely very important in a modern user interface, but also depends on the user group. Shell is a relatively low level interface, it's fair for this ticket to have a lower priority.

Low-quality localized messages

In some circumstances, there's no standard translation for some technical terms, which makes translation job ever harder.

[xiaq]

@xofyarg Can you elaborate what you mean by "enumerating them and give the opportunity to users"?

[xofyarg]

I mean, instead of printing a fixed error string directly, how about letting CLI/WebUI decide how to render the error object? It can load some kind of template during start, and for instance output only the error type to help scripting, throw out a short message for experienced users, or print out a detailed help message, with examples, and even in user's native language to help new user understand what to do next.

[krader1961]

I downvoted the above question by @xiaq precisely because, as an American, I personally would not benefit from implementing this feature. My worry is that we're making it needlessly difficult for non-native ESL speakers to adopt and enjoy using elvish. Note that the way message translation libraries work means that if there is no translation the default, English in this case, messages are used.

The question isn't should translations be available but should it be possible to create and use message translations? If the code doesn't provide support for i18n/L10n message translation then it is impossible to create non-English equivalents. If it does provide that internationalization support it doesn't need to provide message translations for any particular language. Translation to a particular language would only occur when someone was passionate about the issue and the owners of the project were convinced enough people who read that language had begun using elvish to make the cost worthwhile.

P.S., Message translation libraries also have mechanisms to deal with "bit rot". That is, where the default messages have changed but a translation is out of date. In that case, yes, you get the default, English, message.