Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More languages #243

Open
FernandoHCFaria opened this issue Oct 11, 2024 · 11 comments
Open

More languages #243

FernandoHCFaria opened this issue Oct 11, 2024 · 11 comments

Comments

@FernandoHCFaria
Copy link

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.

@luke-
Copy link
Collaborator

luke- commented Oct 12, 2024

@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?

@luke-
Copy link
Collaborator

luke- commented Oct 12, 2024

Besides the "first page", we have also some Marketplace (Playstore/Apple Store) texts.

@marc-farre
Copy link
Collaborator

@PrimozRatej Before answering this question, can you tell me how these language files are created?
https://github.com/humhub/app/tree/master/lib/l10n

@PrimozRatej
Copy link
Collaborator

@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.

@marc-farre
Copy link
Collaborator

@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:

  1. convert again the PHP updated translations to the DART JSON files.
  2. update the Marketplace translations via Google and Apple API

@ArchBlood
Copy link

@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:

  1. convert again the PHP updated translations to the DART JSON files.
  2. 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. 🤔

@marc-farre
Copy link
Collaborator

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.

@luke-
Copy link
Collaborator

luke- commented Oct 14, 2024

@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-translations there is a Github Actions which converts the app PHP array file into JSON and create a PR in the app Repo
  • For the marketplace messages, there is probably manual work required.

@marc-farre
Copy link
Collaborator

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).

@luke-
Copy link
Collaborator

luke- commented Oct 14, 2024

Created Repo and Issue here: https://github.com/humhub/app-translations/issues/1

@ArchBlood
Copy link

@luke- whenever it is ready I have a app_ja.arb file ready just in case it is needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants