Infobox localization for 2.0

[Tertius]

How can overhauled infobox templates better support localization?

Current state and editor workflow:

• infobox content is created as English text
• localization editors translate the English text to their language in notepad
• then Editors edit the language template and add a lookup pair <english text> = <localized text>
• if the field with the English text wasn't yet marked for translation lookup, the template needs to be edited and the field marked for translation lookup

This workflow has at least these issues:

• to verify the correct translation, the editor has to wait for the changes to propagate through the cache, then reload the page with the infobox.
• if the original English text wasn't verbatim copied to the language template, the editor has to go through the editing loop again
• if the original English is changed by some editor later, all the translation templates for every language have to be edited and the text changed as well, because it is used as lookup key.

Potential for improvement:

• items, item names, item properties, localized item descriptions are available in a machine readable format in the original game, so much text doesn't need to be added manually by editors at all but instead generated from the game files
• if some infobox text is generated from game data, even the whole item pages with their infoboxes can be generated from game data, because that's available in the *.lua files provided for mods. This could make the wiki go life on the first day of the expansion with all item pages and infoboxes for all items pre-existing and filled with the most important data already with no editor required to create them.
• if values can differ because of activated expansions or expansion parts, expensive mode, quality, and may be other game features, dynamic generation of these values can be considered. Relevant base data could be converted from *.lua to Javascript, then Javascript functions included by the wiki and compute actual values in the infobox dynamically, depending on chosen parameters.

[Tertius]

As requested, a thread about infobox localization. I admit, I added another scope: automated generation not only for localization but for the whole infobox content. This belongs together, because it is similar in spirit and will influence the mechanics of the automated importer. This importer will read relevant information from the game data, then format this in wiki-usable format and upload it to the wiki. Not only localized text can be pulled from the game data but also recipe data and item properties.

[Tertius]

Finally, a proposal for the concept of automated localization:

In files like Factorio\data\core\locale\<language>\core.cfg and Factorio\data\base\locale\<language>\base.cfg, all text displayed by the game is available as localized text.
The files are structured similar to *.ini files, i. e. every text has a category and a key. For example, the centrifuge description can be found as [entity-description].[centrifuge] which gets "Process various uranium-related recipes." as text in the "en" language.

As value in the infoboxes, insert this key instead of plain text, then let a lookup macro (here: "Infobox-Text") pull the actual text from a dictionary into the web page:
{{Infobox-Text|[entity-description|centrifuge}}

An importer will generate a wiki template, one for each language, each with a {{#switch ... }} construct, that acts as dictionary.

For different forms, such as plural, or text that isn't present in the game files, the editors need to create a second dictionary manually. The macro then has to look up 2 different dictionaries. One generated and the one manually filled.

[Bilka]

I see the problems this solves, changed English text is indeed an issue. Although I try to propagate changes to the English text through to the other languages, some stuff always gets missed. And more automation would always be great.

But I also see problems this creates (besides the initial investment needed to implement it which I would ignore for now):
The translation system is also used on the page, not just in infoboxes, e.g. for TransLink ({{L|Iron plate}}) or the plain {{Translation|Plastic bar}}. If this uses the keys instead of the direct names, then it makes it harder for translators to use these, since they then need to know the internal name of the item. Same goes for creating the manual dictionaries, unless those would not use the key format (which would create the original problem of changed English text again).

An interesting issue that I encountered in an unrelated open source project is that when you have unchanging keys, changed English text will be missed because it's not tracked anywhere. Now, in the case of the automated item names that wouldn't be a problem because crowdin does track changes to the English text and the wiki would just be based on the in-game translations (sourced from crowdin). But for any manual/custom keys that problem would also affect us. That's intended if the en change is just a typo fix or something, but if it is a change that should be propagated it then gets lost.

So it's a bit of a tradeoff between the one - translations break for irrelevant en changes - and the other - translations don't notice relevant en changes. We already have this tracking/notice problem with translated pages overall, see e.g. https://wiki.factorio.com/User_talk:Bil ... rification.

Furthermore, not all languages have a full translation in-game, so the system would gain the complexity of handling this somehow. This would be especially relevant when a version is new and crowdin translations haven't made it into the game yet.

to verify the correct translation, the editor has to wait for the changes to propagate through the cache, then reload the page with the infobox.

You should be able to force the cache of the page to be cleared by selecting the "Refresh" item in the "more" page actions dropdown in the top right of the page, next to Edit and View History. Though it's possible that option is only visible to admins, if that is the case please tell me so I can see if I can change that.

the whole item pages with their infoboxes can be generated from game data, because that's available in the *.lua files provided for mods. This could make the wiki go life on the first day of the expansion with all item pages and infoboxes for all items pre-existing and filled with the most important data already with no editor required to create them.

Infoboxes are already partially automated, see the edits done by BilkaBot. This greatly assisted in updating the wiki starting with 0.15 and I hope to deal with the technical complexities of the expansion related infoboxes before release so we can make use of this automated process again.