Added the localization mechanism for levels and cards

[m0rp30]

I make the localization mechanism for levels and cards and i add the italian localization, that is the instructions to add cards and leves localizatoin.

• Add the localization text into the section "description" in the file ./resource/cards.json

Example:
"description": {
"en_EN": "Drag this card into the empty space above to initialize the time machine!",
"it_IT": "Trascina questa carta nell'area vuota sopra per inizializzare la macchina del tempo",
"es_ES": "Arrastre esta tarjeta al área en blanco de arriba para inicializar la máquina del tiempo"
}

• Add, into the directory levels, the directory with the levels do you want to adding (es. ./levels/fr_FR/LIVELLI )
• Add, the localization into the dictionary game.langs (es. var langs = {0: "en_EN", 1: "it_IT", 2: "es_ES"} the first and default localization it must be en_EN
• Add column of specific locale and relative traductions for avery keys in the file ./resource/localization.csv

Example:

keys,en,it,es
LEVELS,Livels,Livelli,niveles
QUIT,Quit,Esci,Salir
BACK,Back,Indietro,Espalda

If one or more localizations in the descriptions of cards are missing and levels require that card, the game crashes!

[schokotets]

Thank you so much @m0rp30 for your contribution and extensive translation! It really helps improving the project by making it accessible to a larger audience.

I've noticed a few inconsistencies considering naming of functions and explicitly/implicitly translating strings. See the pull request #129 thread for a more general discussion about the modalities and structure of translation.

[schokotets]

would we want to add quotation marks around the values here for consistency's sake?
later in the file, there are quotation marks around each value, yet not each key.

[schokotets]

is this the way we want the game to behave? what about setting a default language & automatically appending a hint, e.g. "[tr]", to notice that it still needs translation.

[schokotets]

Do we want to implicitly translate the given text, looking for strings in the translation?
Note that Godot seems to translate implicity: the tr function only converts the argument if found: Docs
Or would we, instead, prefer having two methods:

• one that notifies the given string
• one that notifies by key

[schokotets]

By the way, we could also consider translating the game's credits - they're located in three different spots:

scenes/title.tscn
24:text = "by bleeptrack & blinry"

scenes/survey.tscn
46:text = "by bleeptrack & blinry"

scenes/no_git.tscn
33:text = "by bleeptrack & blinry"

[schokotets]

Thanks again @m0rp30 for your contribution! It's valuable to have a working implementation -- this moves the project in the right direction and helps the discussion on how to implement i18n.

I've discussed technical details and the modalities of i18n with @blinry. We noticed that, in this project, there are two main aspects of translation:

• non-level translation: general translation of button texts etc. (resources/localizations.csv )
• level translation: translating level texts. could be more extensive, with localized file names, specialized commands, culture-appropriate storylines.

Below is a list on what we agreed on & provide the reasons. This is not a final stance, rather a draft up for discussion.

1. split up the non-level translation file

• problem: having multiple languages on the same line will hinder concurrent translation into multiple languages because of merge conflicts
• solution: using multiple files for different languages to minimize conflicts.

2. use existing tooling for i18n (at least for non-level translation)

• problem: telling progress on different language's translation status
• problem: requiring bare text editors to translate would be a barrier to non-technical people interested in helping translation
• solution: use GNU gettext tooling
• Godot already supports gettext file format
• afaict gettext can automatically extract strings from code, providing context (e.g. line numbers) for the strings in the .po files

3. refactoring the structure of per-level translation

• problem: having high-level folders per language allows different level structures per locale, which hinders and complicates development that modifies e.g. the sequence of levels
• solution: differentiate by-locale on a lower layer, e.g. create a folder per level part & per-locale files differentiated by suffix

4. consistency

• use ISO language strings (e.g. en_US instead of en_EN) everywhere the locale is referenced

What are your thoughts on this, @m0rp30 ? Are you interested in continuing to work on this pull request, or would you like to hand it off to others?

Will reference this discussion in #18

[m0rp30]

Thanks again @m0rp30 for your contribution! It's valuable to have a working implementation -- this moves the project in the right direction and helps the discussion on how to implement i18n.

I've discussed technical details and the modalities of i18n with @blinry. We noticed that, in this project, there are two main aspects of translation:

• non-level translation: general translation of button texts etc. (resources/localizations.csv )
• level translation: translating level texts. could be more extensive, with localized file names, specialized commands, culture-appropriate storylines.

Below is a list on what we agreed on & provide the reasons. This is not a final stance, rather a draft up for discussion.

1. split up the non-level translation file

• problem: having multiple languages on the same line will hinder concurrent translation into multiple languages because of merge conflicts
• solution: using multiple files for different languages to minimize conflicts.

2. use existing tooling for i18n (at least for non-level translation)

• problem: telling progress on different language's translation status
• problem: requiring bare text editors to translate would be a barrier to non-technical people interested in helping translation
• solution: use GNU gettext tooling
• Godot already supports gettext file format
• afaict gettext can automatically extract strings from code, providing context (e.g. line numbers) for the strings in the .po files

3. refactoring the structure of per-level translation

• problem: having high-level folders per language allows different level structures per locale, which hinders and complicates development that modifies e.g. the sequence of levels
• solution: differentiate by-locale on a lower layer, e.g. create a folder per level part & per-locale files differentiated by suffix

4. consistency

• use ISO language strings (e.g. en_US instead of en_EN) everywhere the locale is referenced

What are your thoughts on this, @m0rp30 ? Are you interested in continuing to work on this pull request, or would you like to hand it off to others?

Will reference this discussion in #18

@schokotets i'm very happy to this !!! The free time isn't to much but i try to do this

[schokotets]

Amazing, I'm glad to hear that! Feel free to ask questions in this pull request thread, for example, when you realize that what we suggested might be better done another way.

…

On Wed, 17 Aug 2022, 10:26 Luca Canali, ***@***.***> wrote: Thanks again @m0rp30 <https://github.com/m0rp30> for your contribution! It's valuable to have a working implementation -- this moves the project in the right direction and helps the discussion on how to implement i18n. I've discussed technical details and the modalities of i18n with @blinry <https://github.com/blinry>. We noticed that, in this project, there are two main aspects of translation: - *non-level translation:* general translation of button texts etc. ( resources/localizations.csv ) - *level translation:* translating level texts. could be more extensive, with localized file names, specialized commands, culture-appropriate storylines. Below is a list on what we agreed on & provide the reasons. This is not a final stance, rather a draft up for discussion. 1. split up the non-level translation file - problem: having multiple languages on the same line will hinder concurrent translation into multiple languages because of merge conflicts - solution: using multiple files for different languages to minimize conflicts. 1. use existing tooling for i18n (at least for non-level translation) - problem: telling progress on different language's translation status - problem: requiring bare text editors to translate would be a barrier to non-technical people interested in helping translation - solution: use GNU gettext <https://www.gnu.org/software/gettext/> tooling - Godot already supports gettext file format <https://docs.godotengine.org/en/3.5/tutorials/i18n/localization_using_gettext.html> - afaict gettext can automatically extract strings from code, providing context (e.g. line numbers) for the strings in the .po files 1. refactoring the structure of per-level translation - problem: having high-level folders per language allows different level structures per locale, which hinders and complicates development that modifies e.g. the sequence of levels - solution: differentiate by-locale on a lower layer, e.g. create a folder per level part & per-locale files differentiated by suffix 1. consistency - use ISO language strings (e.g. en_US instead of en_EN) everywhere the locale is referenced What are your thoughts on this, @m0rp30 <https://github.com/m0rp30> ? Are you interested in continuing to work on this pull request, or would you like to hand it off to others? Will reference this discussion in #18 <#18> I'm very happy to this !!! The free time isn't to much but i try to do this — Reply to this email directly, view it on GitHub <#129 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADF3NFJHPK6EIRK3CQTP2Q3VZSO47ANCNFSM5EYX2NDQ> . You are receiving this because you commented.Message ID: ***@***.***>

[m0rp30]

Add new pull request with new mechanism

[schokotets]

discussion continues in pr #146