Manage translation in one place

apple502j commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

VFDan commented 3 years ago

However Crowdin has a much cheaper plan

Ascor8522 commented 3 years ago

Transifex:

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

Kenny2github commented 3 years ago

the Transifex was taken down

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

Kenny2github commented 3 years ago

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

[x] is also free of charge for open source projects
[x] supports every language we do (I assume, I couldn't be bothered to check the whole list)
[x] 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
[x] is endorsed by Electron
[x] also has full automation support
[x] also supports logging in with GH
[x] also supports JSON as a format
[x] also has a glossary
[x] also has comments
[x] also supports multiple managers
[x] also has a dashboard
[x] also has notifications for new strings
[x] 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 commented 3 years ago

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:

[x] is already used by Wikimedia for MediaWiki extensions and skins they maintain - our exact situation
[x] makes use of qqq.json so that we don't have to copy all documentation over to another platform
[x] 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 commented 3 years ago

[x] 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, World!</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.

2.

[x] 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.

3.

[x] 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 commented 3 years ago

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.)

Ascor8522 commented 3 years ago

I want translators who are already familiar with wikitext syntax. I'd prefer one knowledged translator per language over many ignorant ones.

That's why you're supposed to apply for a team when wanting to join a translation team. Just sayin'. Also wondering if it's your personnal opinion or the ISW org's opinion...

Also, you seem to be indoctrinated to the Scratch-Transifexian belief of "tags bad".

I'm just convinced it's easier to translate real English words than markup you have no idea what it does. Remember not all the translators migh be Mediawiki experts, nor JSON experts. And it's the developpers' job to take that into account. Translators are translators, not computer scientists.

quite a few of which are to reduce the number of times wfMessage or other methods have to be called.

I'd be glad if you could quote a paragraph talking about that. Also, keep in mind most of the translations will only run when a user performs a very specific action, thus not so often. Also there aren't that many translations at the time, so it won't overload the server either.

Special page names are not translated

Yes, Special Pages are translated to some extend, but I was mainly talking about custom namespaces that would need to be "translated" (pick the corresponding page in the right namespace on the other wiki)

* Translate special page names, magic words and namespaces on <tvar|adv-tran>[[Special:AdvancedTranslate]]</> (temporarily disabled; see the section #AdvancedTranslate in this document and phab:T109235)

(the line above is only crossed out because of a technical bug, not because it's a bad practice)

Translating namespace names [...] Namespace names can be translated. If they aren't translated, they will appear in the fallback language. English namespace names can always be used in links to pages instead of the translated names.

[...] string keys are hyphenated-lowercase, not camelCase or underscore_case.

You should have a look at this at some point.

👉 Anyway, that being said, keep in mind we don't have very specific needs, so a generic solution would work like a charm. Whatever we end up choosing, being Transifex, Crowdin or anything else should be easily usable and user friendly. The goal is to get enough volunteers, not necessarly the best integrated system.

Kenny2github commented 3 years ago

Also wondering if it's your personnal opinion or the ISW org's opinion...

My personal opinion.

I'm just convinced it's easier to translate real English words than markup...

Why do you even care? Transifex hides tags into a convenient (1|tag|1) pair. I haven't yet been able to figure out what ext:Translate does, but I'm sure it's something similar.

I'd be glad if you could quote a paragraph talking about that.

I say this from my own judgement - Lorem ipsum dolor sit amet takes only one call, while $1 amet + $1 ipsum $2 + Lorem + dolor is 4 MediaWiki parser calls.

Special page names are not translated

I meant this contextually - for this extension, special page names are not translated. Thus they can be hardcoded instead. Also, English namespace names work on all wikis, while other languages don't - though I should really be using {{ns:special}}

You should have a look at this at some point.

MediaWiki convention overrides JSON convention. It's MediaWiki:Requestaccount-text, not RequestaccountText or Requestaccount_text.

I should say that I'm not opposed to Transifex - I'm just currently more enthusiastically in favor of ext:Translate. If it turns out more interwiki admins than just you would prefer it, then I'm happy to use it.

VFDan commented 3 years ago

IMO Transifex is better since I'd say most if not all interwiki admins translate Scratch, which uses Transifex. It's easier to use a system that you already know rather than using another one as with Crowdin or the MW extension.

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).

This is a very valid point ^^

Kenny2github commented 3 years ago

This is a very valid point

Not when you consider my preference for wikitext knowledge. I'm happy having the iw admins on Transifex, but someone who knows nothing about wikis, even in general? nah, they wouldn't be able to understand enough context even if it was given.

VFDan commented 3 years ago

You have to be accepted on Transifex iirc...

ahmetlii commented 3 years ago

I think that MW translate extension is a better idea, especially for references and templates. However, you need to setup a whole server for each language or edit the extension for each language's prefix

VFDan commented 3 years ago

I think that ext:Translate is better since we're updating anyway, and the points Ken made outweigh the Transifex points.

InternationalScratchWiki / ScratchWikiSkin2

Manage translation in one place #60