lvgl / lv_i18n

Internationalization (i18n) for LVGL
MIT License
59 stars 17 forks source link

Workflow summary #9

Closed kisvegabor closed 5 years ago

kisvegabor commented 5 years ago

According to my current understanding, the workflow is something like this:

First translation

  1. The user uses _ and _p in the code
  2. Create some yaml files to indicate which languages are required (e.g. en_gb.yaml, ru_ru.yaml)
  3. Runs the extract script to fill the yaml files with msgids and add placeholders for the translations. For plural msgids the correct number of translation placeholders will be inserted because the extract knows the rules (based on the yaml file's name, e.g. en_gb).
  4. Send the yaml files for translation
  5. When received the compile script is called to generate the C file(s). The generated C file(s) will contain the plural rules and other language-specific things because this information is known by compile.

Update with new msgids

  1. Add/remove/delete some msgids
  2. Run merge to update the yaml files
  3. Send the yaml files for translation
  4. Run compile to update the C file(s)

Am I seeing well?

puzrin commented 5 years ago

2. Create some yaml files to indicate which languages are required (e.g. en_gb.yaml, ru_ru.yaml)

That's not required. Scanner create it automatically if not exists. You only need to pass destination and default locale in options.

4. Send the yaml files for translation

I'd say publish on github & compile immediately. Then recompine when yaml files updated somehow.

Am I seeing well?

Yes.

kisvegabor commented 5 years ago

That's not required. Scanner create it automatically if not exists. You only need to pass destination and default locale in options.

Can you write an example use of the extract script? Just to be sure we think about the same thing.

puzrin commented 5 years ago

Splited to multiple lines for convenience

lv-i18n extract
--source ./src
--source ./src2/**.cpp
--outfiles ./i18n/*.yml
--deflocale en-US
--outnew new_phrases.yml

That's only a very preliminary sample. Everything may be changed.

With high probability, users will store each locale in separate file (en-GB.yml). Script will detect locale name in yaml and merge data to proper place. If you have nothing at all, it will create <default_locale>.yml.

If --outnew exists - new phrases will go to separate file instead of merge. Not sure if needed. We still have git diff...

Every non-default locale will be extended automatically with missed translations (null-filled keys). To create new locale - just add file like ru-RU.yml with content ru-RU: {} (or empty at all)

kisvegabor commented 5 years ago

Clear, thanks!

puzrin commented 5 years ago

Close - details landed to docs (readme)