Talk:Translatable modules

Feedback from Base
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)
 * So just in case I mean creating something like Template:Graphs/i18n.tab with content like


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