search

git-learning-game / oh-my-git

An interactive Git learning game!
https://ohmygit.org
Other
2.04k stars 146 forks source link

Added the localization mechanism for levels and cards #129

Closed m0rp30 closed 2 years ago

m0rp30 commented 3 years ago

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.

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" }

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 commented 2 years ago

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 commented 2 years ago

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:

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 commented 2 years ago

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.
  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 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
  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 ? 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 commented 2 years ago

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.

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

  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 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 https://github.com/git-learning-game/oh-my-git/issues/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 https://github.com/git-learning-game/oh-my-git/pull/129#issuecomment-1217676733, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADF3NFJHPK6EIRK3CQTP2Q3VZSO47ANCNFSM5EYX2NDQ . You are receiving this because you commented.Message ID: @.***>

m0rp30 commented 2 years ago

Add new pull request with new mechanism

schokotets commented 2 years ago

discussion continues in pr #146