Problem

There is one file for each language, Locale/$LANGUAGE/config.lua, that contains a list of key-value pairs like ['SOME_DESCRIPTOR'] = 'Some UI text'. This approach has some downsides:

• Using SOME_DESCRIPTOR in code means developers might need to (reverse-)lookup the actual English text, instead of just seeing it in the code. Same problem for translators, they might need to lookup the English original before adding/correcting a translation.
• To add new interface texts developers need to add it to every language file, if they don't translators will have a hard time finding missing translations. There is no convention on how missing translations are marked for easy lookup.

Solution

Put all translations into one table, using the English text instead of a descriptor as table key, every entry has a default ['myLang'] = false sub-entry for every language:

local Locales = {
    ['Icon Limit'] = {
        ['deDE'] = false,
        ['enUS'] = true,
        ['frFR'] = "Limite d'icônes",
        ['ptBR'] = "Limite de ícone",
        ['esMX'] = "Límite de icono",
        ['zhCN'] = "图标限制",
        ['koKR'] = "아이콘 개수 제한",
        ['zhTW'] = "圖示限制",
        ['ruRU'] = "Лимит количества значков",
        ['esES'] = "Límite de icono",
    },
    ['Enable or disable Questie auto-accepting quests.'] = {
...

In this example false indicates a missing translation, so translators can just search for ['myLang'] = false to find all missing translations. They immediately see the English original without opening another file.

The value true indicates that the (English) table key is to be used as the text. This is mainly used for enUS entries, but might affect some edge cases where other languages use anglicisms (or vice versa), or if we choose to add enGB localisation later on.

A string indicates a translation.

We could theoretically support overwriting to arbitrary languages translation later by using integers. Could be useful for esMX/esES for example.

Discussion

The example is taken from an auto-generated file. To generate the full file go to the ExternalScripts(DONOTINCLUDEINRELEASE) dir and run lua reformat.lua. This will create two new files, Step.lua and Locales.lua.

To functionally use this new Locales.lua file all the occurrences of the keys in Step.lua that appear in Questies code would have to be replaced with the enUS values, and the localisation module needs a slight refactoring to use the new file instead of the old separate config.lua files.

This should make the workflow a lot easier both for translators as well as developers. One downside is that long interface texts might make the actual code more verbose in some places.

There is no concrete plan for when exactly this will be implemented or if it will be implemented like this, but it will not be in the upcoming release. Suggestions and question are welcome.

CC

Tagging some recent translators for heads-up and comment:

@anon1231823 @nanjuekaien1 @Hantunaar @iron217 @arithmandar

Hey @BreakBB ,

Is this something you would have time to do before BC launch? Seems like an important bit of work, got brought up in our team meetings twice I think even.

Well this is a lot of work but not much of thinking required. So it should totally be possible yeah 👍

Adding all translations into one single file would make this file really huge! And I am not a fan of huge files.

I would suggest to split the file and either add them to the module where the translations are used or keep them in the Locale directory and mirror the sections/modules there. Like Locale/Journey.lua (for the translations related to the Journey) and Locale/Config.lua (for the translations related to the Questie settings).

This could be done on top of the changes mentioned above.

Moreover I think that the verbosity of the changes in the code will be not too bad for most cases or maybe even "force" us to shorten the texts and keep it simple.

I think this is a great solution

When refactoring the translation system we should also make our QuestieLocale:GetUIString callable to be shorter. Other addons use the Ace L['some text'] which we could translate to use our module. This might also help to make the code not too verbose.

Making a module callable is quite easy using meta tables:

setmetatable(QuestieLocale, {__call = function(_, ...) return QuestieLocale:GetUIString(...) end})

@AeroScripts we should get this into Master so that it'll be easier for various things to be translated. Likely we'll get some PRs from other folks as we get ready for pre-patch.

Fixed with #2585