More languages
It would be awesome if more languages could be add in the first page of the app like pt-BR for instance.
I can help for pt-BR translation if needed btw.
@marc-farre Do you have any idea how we could organize this? Maybe somehow via the Translate community and the wiki within the language Spaces?
Besides the "first page", we have also some Marketplace (Playstore/Apple Store) texts.
@PrimozRatej Before answering this question, can you tell me how these language files are created? https://github.com/humhub/app/tree/master/lib/l10n
@marc-farre, they are created manually. Then, the Flutter generator creates an override class, which is used inside the code. If we want to add another language, we just create a new ARB file here, and then I add another supported_locale in the code, and that's it.
@PrimozRatej thanks.
@luke- Ideally, we would manage the translations with the translation module, using https://translate.humhub.org/translation/translate
Perhaps my idea is complicated, but what do you think about full automation, which would prevent human errors (mainly when we have new texts):
1/ In the https://github.com/humhub/app/blob/master/lib/l10n/app_en.arb file, we store all translations, including the Marketplace texts (or we create a separated file for the Marketplace)
2/ A GitHub Action (after each commit) executes PHP code to convert this JSON file into PHP array stored in files in a messages root directory (one sub-directory by language in supported_locale), like any HumHub modules.
3/ We make the app available in https://translate.humhub.org/translation/translate for translations
4/ Another GitHub Action (triggered when creating a new release - release event, prereleased type) would:
- convert again the PHP updated translations to the DART JSON files.
- update the Marketplace translations via Google and Apple API
@PrimozRatej thanks.
@luke- Ideally, we would manage the translations with the
translationmodule, using https://translate.humhub.org/translation/translatePerhaps my idea is complicated, but what do you think about full automation, which would prevent human errors (mainly when we have new texts):
1/ In the https://github.com/humhub/app/blob/master/lib/l10n/app_en.arb file, we store all translations, including the Marketplace texts (or we create a separated file for the Marketplace)
2/ A GitHub Action (after each commit) executes PHP code to convert this JSON file into PHP array stored in files in a
messagesroot directory (one sub-directory by language insupported_locale), like any HumHub modules.3/ We make the app available in https://translate.humhub.org/translation/translate for translations
4/ Another GitHub Action (triggered when creating a new release -
releaseevent,prereleasedtype) would:
- convert again the PHP updated translations to the DART JSON files.
- update the Marketplace translations via Google and Apple API
When it comes to Asian languages, I'd prefer DeepL over Google as they're less error prone in translations if automation were the intent. 🤔
I'd prefer DeepL over Google
@ArchBlood The idea is to allow users to do manual translations via https://translate.humhub.org/translation/translate, but to automate the process to make it possible.
@marc-farre Sounds good. Wouldn't it be nicer if we created a new repository, e.g. 'app-translations'? This has a fake module structure, a 'messages' folder, GitHub actions. The app-translations could have two message files app und marketplace.
- The Translation community pushes changes to the PHP arrays to
app-translations. - In
app-translationsthere is a Github Actions which converts theappPHP array file into JSON and create a PR in theappRepo - For the
marketplacemessages, there is probably manual work required.
Yes, very good idea to create a separated repository. For the Marketplace, we can start doing it manually, but later we can do it via API requests (both Google and Apple provide entry points for these app texts).
Created Repo and Issue here: https://github.com/humhub/app-translations/issues/1
@luke- whenever it is ready I have a app_ja.arb file ready just in case it is needed.