galene
galene copied to clipboard
jech
feat: i18n
Hi,
I set up an i18n module. There are no external dependencies. I loaded 2 available languages (en & fr).
Principipaly this is based on (key, value) JSON file. I inspire myself from the jQuery attribute data-i18n.
In the HTML file:
<h1 data-i18n="app"></h1>
In the JavaScript files:
displayError(trans.get('disconnected'), 'error');
Fix: #33
This only translates messages that come from the Javascript, right? Or am I missing something and does it also translate the parts of the UI that are in HTML?
The translation is supported on both sides.
Only some error messages are not supported, because there are directly given by the server.
https://user-images.githubusercontent.com/40602497/110239150-de101900-7f45-11eb-8efd-f777947d41f5.mov
How Translation.prototype.selectLanguage = function (language) works? Does it parse all the languages in the header accepted_language or only the first one?
I didn't use any header as Accepted-Language. Should I (maybe I missed something)? I touched only the client-side. The serve didn't know which language the user uses.
Translation.prototype.selectLanguage = function (language){
this.language = this.languages.filter(l => l === language).length === 1 ? language : this.default;
}
This method will initialize the field this.language in the constructor. By default, I use the field navigator.language.
The method Translation.prototype.analyse will analyze the HTML and will set the right value related to the key stored by the attribute data-i18n.
I meant, does it read all the languages a user has chosen or only the first one? I don't see a loop and I don't understand turner things :S
The patch uses the navigator.language value. As @inlor suggested, it should probably loop over navigator.languages (notice the s at the end) and pick the first language for which a translation is available, but that can be added in a future version.
For now, the important things to decide are:
- is this feature worth the extra maintenance burden?
- is this the right approach, or should we be using the English strings as indices in the translation table, as is the case with GNU gettext?
I have little experience with translation (I'm usually into software in English but with full support for non-ASCII scripts), so I'd welcome advice on both points above.
- I don't think that this feature will grow up the maintainability (after all, there are only messages).
- I saw examples here, to my mind usage of English string instead of key seems to be fragile. But, if you think that is better, I can change it @jech.
@Mejans seems to have some experience with i18n modules.
I usually translate and some times I write code :) And often I see some web sites only take the first language then falling back to English whereas the second language was available :(
Sorry. I'm currently aiming at getting a stable 0.3.3 out, with no new features, just fixes. I'll think about this after 0.3.3 is out.