The site is currently untranslatable, as far as I know. I suspect strings are also hardcoded in the code, which is the perfect recipe to achieve messaging of extremely low quality.
For MediaWiki we apply the principle that i18n after day 0 is already too late. You're quite into development by now...
Version: unspecified
Severity: enhancement
I agree with the principle but I don't know how should we proceed. Can we
leverage e.g. TranslateWiki.net somehow?
Also, how would the access to the different languages be done?
Connected to this, I'd rather handle most/all the text strings as variables
somewhere, in order to avoid direct HTML editing via GitHub pull requests...
Yes, it's possible to use translatewiki.net; all translators can translate in all languages and projects there.
The easiest way might be Intuition (i18n framework for labs) https://github.com/Krinkle/TsIntuition/wiki/Documentation#usage ; otherwise, JSON is one supported format (see https://translatewiki.net/wiki/Translating:New_project ).
Nemo, pretty cool. Right now we are not using any 18n/l10n framework and only EEUU/UK is supported. I am not pretty sure about the priority we are going to put for this important task in our development.
In order to have more info:
Cheers
(In reply to comment #3)
- Could we use TsIntuition outside Wikimedia gerrit?
It's only on GitHub.
- Is it time to move the dashboard to Wikimedia gerrit? Is there a formal
process to follow? Is it a good idea?
No idea and it doesn't matter for this bug.
(In reply to comment #4)
(In reply to comment #3)
- Could we use TsIntuition outside Wikimedia gerrit?
It's only on GitHub.
I was thinking in using the full translatewiki.net process, this is why I was thinking in the need to be in Wikimedia gerrit.
TsIntuition seems to be design for using with PHP. Right now the dashboard is totally client side (maybe this could change in the future) so I think we need a Javascript i18n/l10n framework for managing the translated strings (i18n) and also the localization. And the tool used for translating the string, I am not sure about it.
- Is it time to move the dashboard to Wikimedia gerrit? Is there a formal
process to follow? Is it a good idea?
No idea and it doesn't matter for this bug.
Right. I was thinking in reusing the full translate process in Wikimedia. This is why I was thinking in the need to upload the project to Wikimedia gerrit.
As implied above, GitHub is supported by translatewiki.net, see instructions linked from comment 2. Thanks for your interest!
For frontend i18n you can consider using jquery.i18n (can be found on github) and json file format. This is the direction MediaWiki itself is going as well, though it will use ResourceLoader for loading messages.
In fact, even if the principle of i18n/L10n is always good (says the non-native English speaker), considering that korma is about tech metrics and most of our tech spaces are in English only, it is fair to think that the real need for L10n here is close to none.
I'm not aware of any production Wikimedia statistics site, or any site *about* development, which is *not* localised. Do you have examples?
You got my point: the users of Phabricator, Gerrit, mediawiki.org, developer mailing lists and technical IRC channels are used to read in English, and this is why I believe the current priority of this task is correct.
Even though our tech spaces are mostly in English only, I don't think the audience of korma consists of only developers. I can imagine journalists, community members and others looking at the stats there (even if we publish those in more accessible ways like blog posts). Not to forget the benefits for improved consistency in wording and terminology that usually comes with translation process.
In any case, compared to Phabricator, it looks like it would be much easier to setup i18n for korma. It would be helpful if the link to the source code was somewhere in this task.
Sure. It's possible that the priority is correct but the name of the priority level makes it sound wrong: making code i18n-ready is *always* the maintainers' responsibility.
The priority of this task will be higher if/whenever you want to make this a production-hosted service like stats.wikimedia.org (which has partial i18n) and the gerrit reports (whose i18n is trivial with Translate).
I added a link from the component's description.
For korma.wmflabs.org this request is a WONTFIX/declined as korma.wmflabs.org will get superseded by wikimedia.biterg.io.
Hence rephrasing this ticket and setting task status to stalled, as for wikimedia.biterg.io this would require fixing https://github.com/elastic/kibana/issues/706 first.
Feel free to file an upstream task under the CHAOSS umbrella: https://github.com/chaoss/grimoirelab
We don't plan to work on this request in Wikimedia downstream.
No plans to work on this and there is nothing to track downstream - see last comment. If anyone decides to work on this in upstream we'll get that update anyway.