Hey, For PHP libraries such DataModel, all the overhead of the translation setup is not worthwhile just to have the thing on Special:Version be translated. Indeed, a good portion of these libraries don't even add anything to Special:Version to begin with. Components with messages should of course have translatewiki support. As you mention, this can be done by syncing the GitHub repo with the WMF one, as done with for instance Maps. I suggest filing issues for those where this is not done yet. Of course if we want to avoid new repos being created and them not being set up in this way because it's such a hassle, then the obvious thing to do is to make translatewiki not bound to the WMF git repos. Cheers -- Jeroen De Dauw - http://www.bn2vs.com Software craftsmanship advocate Evil software architect at Wikimedia Germany ~=[,,_,,]:3

Hi Amir, tere must be working exort scripts to github, since we translate e.g. etherpad lite, which is maintained on github, and there are commits from translatewiki.net, see: https://github.com/ether/etherpad-lite/tree/develop/src/locales Purodha "Amir E. Aharoni" <amir.aharoni(a)mail.huji.ac.il> wrote Hi,   Several Wikidata-related extensions are not translatable on translatewiki.net[http://translatewiki.net].   The ones I could find are: * Wikibase DataModel * Wikibase DataModel JavaScript * Wikidata build * WikimediaBadges * The various DataValues extensions   All extensions need at least a translatable description for Special:Version, and some of the above have actual messages to translate.   If I understand correctly, the reasons for this is that it's more comfortable for their developers to have the code review in GitHub, and translatewiki's MediaWiki extensions L10n export scripts work only with Gerrit. The question is, is it feasible to sync GitHub and Gerrit, so that these extensions would be easily translatable?   If I understand correctly, something like this is already done for some MediaWiki extensions, among the SemanticResultFormats and Maps. Thanks for any assistance.