Manage translation in one place

[apple502j]

Currently, translations are submitted in pull requests for i18n JSON. Somebody created a Transifex organization, so it's time to decide on a single method of submitting translations before we get carried away with Transifex.

[Kenny2github]

The Transifex org is not official (yet) and shouldn't be considered a second way to submit translations. @Ascor8522 please don't create things with official names if you are not the representative. You represent the French wikis, not all of the wikis.

[Kenny2github]

I've edited the OP after new information has come to light. I don't know enough about any translation platform to be anything but indifferent, though in my hazy memory I seem to recall that Transifex costs money?

[VFDan]

Well the Transifex was taken down but yes it costs a lot of money.

[VFDan]

However Crowdin has a much cheaper plan

[Ascor8522]

Transifex:

• is free of charge for open sources projects, like the ones hosted at the International Scratch Wiki org
• has support for all the languages we support at the Test Wiki
• has a reviewing system
• has a large user-base (don't forget about all the voluteers already signed up for the Scratch projects)
• has a team management system
• has full automation support (built-in pull & push to GitHub from new translations, + API for custom system)
• has login via GitHub support, so no need for additional account (since already have to have a GH account to push tranlsations with the current system)
• has support for different formats to input strings to be translated, like json-key-value, like we are currently using at the ISW org.
• has a glossary, to re-use the same translations between strings
• has a comments feature, to let comments on some strings
• can be managed by mutilple people at the time
• has a dashboard to see the overall progress for each language
• has a notification system when new strings are added
• can easily keep track of who submitted what translation

[Kenny2github]

the Transifex was taken down

@VFDan Was it? The link in the OP still works fine and I have access to the org.

[Kenny2github]

Looking at Crowdin's website, and comparing with Transifex, Crowdin:

• is also free of charge for open source projects
• supports every language we do (I assume, I couldn't be bothered to check the whole list)
• also has a "proofreading" system, which is reviewing under a different name
• though it does have a large userbase, it's admittedly not one that's familiar with the Wikis
• doesn't have team management, but teams aren't ideal - anyone should be allowed to translate anything to their language
• is endorsed by Electron
• also has full automation support
• also supports logging in with GH
• also supports JSON as a format
• also has a glossary
• also has comments
• also supports multiple managers
• also has a dashboard
• also has notifications for new strings
• also has priorities for files

I can't tell if Crowdin has support for custom variables; that being said, Transifex's support for MediaWiki parameter syntax is dodgy because you can only specify things that are delimited (e.g. {variable}) or constant (e.g. %s). The former doesn't work at all, and for the latter we'd have to manually specify every $1, $2, etc as a separate constant variable...

Basically, Crowdin looks like a legitimate competitor to Transifex. However, I have a different suggestion.

[Kenny2github]

I personally am leaning towards the MediaWiki Language Extension Bundle, which is used by MediaWiki themselves to translate MediaWiki itself, in particular using the Translate extension. This probably makes the most sense for translating wiki-related projects. The bundle:

• is already used by Wikimedia for MediaWiki extensions and skins they maintain - our exact situation
• makes use of qqq.json so that we don't have to copy all documentation over to another platform
• is installed on a wiki, which in our case can either be the Test wiki or a new thing like translate.scratch-wiki.info

There are other features which I'm researching at the moment. This is the most logical choice to me, because it doesn't even take us to another website - just use the Wiki!

[Ascor8522]

• doesn't have team management, but teams aren't ideal - anyone should be allowed to translate anything to their language

Transifex requires a bit of tweaking but it should be possible too

While the translate extension seems to fit well for the Mediawiki foundation, I don't think It's the best option out there for us, and that for several reasons:

Transifex's support for MediaWiki parameter syntax is dodgy because you can only specify things that are delimited (e.g. {variable}) or constant (e.g. %s). The former doesn't work at all, and for the latter we'd have to manually specify every $1, $2, etc as a separate constant variable...

I believe we should try to make easier translation files, where the HTML or Mediawiki syntax is already removed instead of leaving all the syntax in there and finding a smarter translation platform

e.g. { "hello_world": "<big>Hello, <u>World</u>!</big>" } should become { "hello": "Hello, $1 !", "world": "World" } with the HTML / MediaWiki syntax hardcoded in the source code.

This way, we could have a more flexible system, and only use a few variable (let's say $1 to $3) and no need to worry about the MW syntax.

Same with Mediawiki syntax:
https://github.com/InternationalScratchWiki/mediawiki-scratch-login/blob/45a9ee44cdf7f3873f0e165b2ec865906af124c7/i18n/en.json#L17
could become { "scratchLogin": "Special:ScratchLogin", "login_with_scratch": "Log in with Scratch" }

We just sometimes may need to add some more infomration about the context and where the string is located / supposed to go.

• makes use of qqq.json so that we don't have to copy all documentation over to another platform

I strongly believe this file is unnecessary, since when developping the extension, strings are tested and added to the English version directly.

• is installed on a wiki, which in our case can either be the Test wiki or a new thing like translate.scratch-wiki.info

It would mean only the users with a Test Wiki account would be able to translate these strings, so a large amount of potential translators are left out (All the ones with GH account who are not part of the Test Scratch Wiki and who just wanted to help with translation).

[Kenny2github]

I want translators who are already familiar with wikitext syntax. I'd prefer one knowledged translator per language over many ignorant ones. Requiring a Test Wiki account helps ensure that. Also, you seem to be indoctrinated to the Scratch-Transifexian belief of "tags bad". In particular, you don't seem to understand MediaWiki translation conventions, quite a few of which are to reduce the number of times wfMessage or other methods have to be called.

We just sometimes may need to add some more infomration about the context

and this is exactly what the qqq.json file is for! The strings in there are shown to explain the context for the string and what goes in the parameters.

My only qualm with the whole idea at the moment is that it's taking me quite a while to figure out how to set it up. I'm playing around with it on my local installation and things seem to be going well, but it'll take some time. Transifex is more out-of-the-box, but it's still not expressly designed with MediaWiki in mind.

(To be fair, the example in scratchlogin-userlogin-link is quite egregious - that formatting really should be hardcoded. Go ahead and open an issue for it, or I'll change that at some point. However, your example change shows your ignorance - Special page names are not translated, and string keys are hyphenated-lowercase, not camelCase or underscore_case.)