Talk:Translatable modules - MediaWiki (original) (raw)

It seems that what Yurik has presented might as well be the solution. Just have those .tab JSON files in MediaWiki format instead, where there is 1 file per language, rather than 1 file with all the languages. Then that one can be tagged for translation and the resulting /ru, /es, /fr pages can be attempted to be called by the module before it falls back to /en. Now the only question is whether tags would work in pages with JSON content module. Or perhaps Translate can be fed those automatically somehow. There is also an issue of escaping to be solved, lest people break those with a stray quote mark, but it is still better than the comma to remember. --Base (talk) 14:43, 2 September 2020 (UTC)Reply

So just in case I mean creating something like Template:Graphs/i18n.tab with content like

"en": <translate>Translation table for the corresponding template</translate>",

Now probably indeed that won't work out of box, since even if Translate picks it, it will attempt to create Template:Graphs/i18n.tab/en and so forth, which does not end with .tab so won't work even if gets created. But I think it should be an easy fix to be made. --Base (talk) 14:47, 2 September 2020 (UTC)Reply

I think the best way would be to add support to translatewiki to directly understand the Data:I18n/*.tab pages. Most templates have very few parameters, so creating guzzillion pages is not really necessary. The extra tags in the raw data may make the system far more complex and less understandable. Note that it should be fairly straightforward to fully automate this process. --Yurik (talk)

Well, the messages themselves will end up as individual pages in Translations namespace this way or the other, be it on Commons or on Translatewiki, so while we can save some on some number of pages, the biggest contribution to that number stays, which renders this saving questionable. But I guess yeah if the process of Translatewiki is automated, then it should be a good way to go. I am only a bit concerned if it would be clear for people that they have to go to Translatewiki to do the translations (which is a separate non-SUL wiki too). --Base (talk) 15:07, 2 September 2020 (UTC)Reply

Fair point. I guess more important than pages is that Module:TNT has been around for a long time and many people are familiar with it, so keeping that approach might make sense. Putting a single translation in a data subpage would require a new module, and will make things a bit slower (it would need to load the primary page and a fallback, resulting in a slowdown). It does fit better with the current translatewiki model though. --Yurik (talk) 15:15, 2 September 2020 (UTC)Reply

Translate tags only work on wikitext pages, and besides, it would be bad usability when we can easily do better and support tab-json pages directly. My main question would be what would be the best workflow: some kind of automatic processing or manual processing similar to translatable pages where you have to (re-)mark pages to 1) register in the system and 2) enable change tracking and fuzzying. Nikerabbit (talk) 08:19, 3 September 2020 (UTC)Reply

Nikerabbit workflow-wise, I think **any** page with the i18n/ and templatedata/ prefixes are ok to automatically add to the translation system. In theory you could say that any page at all with a multilingual string could be added, but at least these two pseudo-namespaces have well established format. Moreover, ideally the translation should be on commons itself, i.e. any edit would go directly into the data page as a regular edit, rather than having an intermediary storage, but with all the benefits of the great translatewiki interface (suggestions, autotranslations, viewing all data pages on a single page for a single language, etc.). If this is not possible (?), the next best thing would be to auto-sync as fast as possible any changes on either side. --Yurik (talk) 22:34, 3 September 2020 (UTC)Reply

In the Data namespace on Commons, there are json files with translateble strings, example: c:Data:COVID-19 hospitalizations in Denmark.tab. It would be great if these also became easier to translate since it would make it much easier to maintain and share data in tables across language versions. Ainali (talk) 09:56, 4 September 2020 (UTC)Reply

Ainali, thanks for the comment!

This may be possible, but I have a few comments and questions:

I can certainly imagine a general use case of JSON files stored as wiki pages, and usable in modules, in templates, and in other places, and translatable in the Translate interface. It must be well-defined how it's done, however. For example, how will the Translate extension know which files to load for translation? It's doable, but needs specification. "Aggregated from various media source" in your example above doesn't appear to be translatable, not even manually, although I might be missing something.

The scope of this project is only modules, but if it can cover other things without a lot of extra effort, then it's conceivable. --Amir E. Aharoni (WMF) (talk) 13:06, 6 September 2020 (UTC)Reply

If you enter edit mode of the file you can see that there are already English, Danish and Swedish translations in it. And Commons actually displays the strings in my language already. They can be used in articles thanks to templates like w:sv:Mall:Json2table. Ainali (talk) 17:11, 6 September 2020 (UTC)Reply

Feeding the JSON entries might be supported from translatewiki community.

There are proven mechanisms available for all purposes, and a unified workflow for all kinds of tools including templates may use them. No need to re-invent the wheel.

Greetings --PerfektesChaos (talk) 16:34, 22 September 2020 (UTC)Reply

Thanks!

My idea is that we should probably not use the translatewiki.net website, but the installation of the Translate extension on the websites here. Commons, Wikidata, mediawiki.org and Meta already have it and it's used a lot. The Translate extension will have to be modified to support the new format.

And yes, the idea is not to reinvent the wheel, and to reuse existing practices and technologies as much as possible. --Amir E. Aharoni (WMF) (talk) 06:37, 23 September 2020 (UTC)Reply

Some notes on global application identifiers:

{ explain: { en: "This page is a [[meta:Soft redirect|soft redirect]].", de: "Diese Seite ist eine „[[w:de:Hilfe:Weiterleitung#soft|weiche Weiterleitung]]“.", fr: "Cette page est une [[meta:Soft redirect/fr|redirection douce]].", hu: "[[meta:Soft redirect/hu|Soft átirányító]] lap", it: "La pagina di [[meta:Soft redirect/it|riferimento]] si trova in un altro sito/progetto.", la: "Haec pagina te [[meta:Soft redirect|ad locum supra adnexum]] dirigere vult.", nl: "Dit is een [[meta:Soft redirect/nl|indirecte doorverwijzing]].", ru: "Эта страница — [[meta:Soft redirect/ru|мягкое перенаправление]]." }, notarget: { en: "missing target", de: "Ziel fehlt" }, syntax: { en: "no link syntax", de: "Keine Wikisyntax" } }

Globally unique package identifiers are to be human readable and self explaining; neither 63A9F2B70C41D853 nor P26375.

Management of globally unique identifiers is a crucial prerequisite to access any translated string later.

Enjoy --PerfektesChaos (talk) 10:27, 23 September 2020 (UTC)Reply

I agree that this approach seems to be the most convenient one. However, from my testing I remember that the Data call can lead to performance issues on a larger scale (discussed it here last year). As long as we are only talking about user interface messages, this will probably not be an issue. But if this solution were to be used as the basis for global modules/templates in the future, I would like to see some statistics on performance first (in comparison to the other solutions presented here). Regards, XanonymusX (talk) 17:52, 30 September 2020 (UTC)Reply

the missing link is phab:T107119, namely, provide a way for lua module to easily and reliably consume tempaltedata.

"Solution":

use "Alias" field of templatedata to list the parameter name expected by the module, or the localized param name.

many, probably most modules already use Module:Arguments to consume their parameters. using Module:Arguments can be made "precondition" for transportability without losing too much "functionality" - converting modules to consume Module:Arguments is relatively small change.

once this is done, "arguments" can be thought of as "translation module". it can work both ways. when either a parameter or its alias have a value, arguments will assign this value to both (as "real" parameter) to the ported module. this way, the importing project can decide whether to define the actual required parameter as "parameter" and use the alias for translation, or vice versa.

the first mode (localized parameter names as aliases) is more logical, but less convenient for tool like wizards, which typically offer the parameters and not the alias. the opposite direction (use the localized parameter, and the expected param name as alias) is less ligical, but more convenient to wizards.

alternatively, templatedata can introduce anther parameter attribute, "localized name" rather than using "alias" field.

some may find this idiom distasteful, but they say wikt:en:there's more than one way to skin a cat. the point is, no matter how you are going to skin it, if you don't _catch_ the cat first, none of them matter.in this case, catching the cat is simply providing scribuntu with access to templatedata.
IOW, resolve phab:T107119 (which will celebrate pretty soon its 10th birthday). its not a great technical challenge or even a lot of work - all it takes is prioritizing it higher.

iirc, an actual patch was offered, it just need one technical correction, and maybe some TLC to get it to. it may not be on par with current PR standards, but if this is the case, any developer can fix that easily enough.

peace. קיפודנחש (talk) 23:13, 14 May 2024 (UTC)Reply

The current mw.ext.translate.messageBundle solution require:

CC: @UOzurumba (WMF)

-- Winston Sung (talk) 13:27, 28 July 2025 (UTC)Reply

Mininum reproducible:

-- Winston Sung (talk) 08:55, 2 August 2025 (UTC)Reply

local tmb = require( "mw.ext.translate.messageBundle" ) local mb_page_title = "Module:Title/i18n" local msg_key = "message-key" -- We're asking for zh-hant translation local lang_tag = "zh-hant" local mb = tmb.new( mb_page_title, lang_tag ) local msg_plain = mb:t( msg_key ):plain() -- we get the zh translation containing zh-hans, zh-hant, zh-hk at the same time, which used a wrapper here: {{LC zh|...|zh-hans = ...|zh-hant = ...|zh-hk = ...}} local msg_text = frame:preprocess( msg_plain ) -- The LC zh wrapper cannot know which lang_tag it is asking for, thus fallback'd to UI language, but not the language we're asking for

-- Winston Sung (talk) 14:40, 2 August 2025 (UTC)Reply

Without using /zh-hans, /zh-hant, /zh-hk, or have something to pass the language tag, we have to manually pass the language tag every time using message bundle messages, otherwise it will fail to get the correct translation for the language.

-- Winston Sung (talk) 05:10, 5 August 2025 (UTC)Reply

Thanks for reaching our Winston, and thanks for the reproducible scenario. I'll review this further with the team.

Regards, APatro (WMF) (talk) 13:43, 18 August 2025 (UTC)Reply