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

Translation of the app #208

Closed
Altonss opened this issue Aug 15, 2022 · 18 comments
Closed

Translation of the app #208

Altonss opened this issue Aug 15, 2022 · 18 comments
Labels
i18n internationalization

Comments

@Altonss
Copy link
Contributor

Altonss commented Aug 15, 2022

Hello!
I really like this app and am really thankful for it being on Fdroid :) It is currently available in english and german, but I think it would be really cool to also have other languages available! What do you think about integrating a translation tool like Weblate to add new languages?

@johan12345 johan12345 added the i18n internationalization label Aug 16, 2022
@johan12345
Copy link
Collaborator

johan12345 commented Aug 16, 2022

Thanks! In principle I think this is a good idea, however we need to keep in mind that:

  • While the app itself would be translated, all information about the chargers that involves free-text fields (such as the name of the charger, and text descriptions about pricing, location or other details) would not. These are typically in German for the GoingElectric.de data source, and either English or the respective local language for OpenChargeMap.
  • The data sources might not have the best coverage in all countries. While GoingElectric.de has chargers all over Europe, it is mainly focused on the German-speaking area. OpenChargeMap imports government open data sources in several countries, but I'm not sure if all the imports are still being updated - and the quality of the crowdsourced data varies a lot by area.
  • The price comparison using Chargeprice only supports four languages so far. So we need to fall back to English in other cases.
  • While I know a little bit of French and Scandinavian languages, I'm probably not able to review the correctness of technical terms in those translations or provide support in those languages.
  • Waiting for a couple of new strings to be translated before a new release might slow down the release process quite a bit. So I would probably not make translations other than English and German mandatory for release, rather let the app fall back to English if needed and include translations later once they are done.
  • For the same reason, I would probably also not translate the changelogs for F-Droid or the Play Store to other languages

So when we add more translations I would suggest also adding a dialog that informs the user that they are using an "unofficial" translation with the caveats mentioned above. There's already a way to set the language within the app, so they can opt to use English or German instead of their system language if preferred.

Do you already have experience with Weblate or other translation platforms and how easy it is to integrate Android XML strings files and to push and pull updates?

@Altonss
Copy link
Contributor Author

Altonss commented Aug 16, 2022

Thanks! In principle I think this is a good idea, however we need to keep in mind that:

* While the app itself would be translated, all information about the chargers that involves free-text fields (such as the name of the charger, and text descriptions about pricing, location or other details) would not. These are typically in German for the GoingElectric.de data source, and either English or the respective local language for OpenChargeMap.
* The data sources might not have the best coverage in all countries. While GoingElectric.de has chargers all over Europe, it is mainly focused on the German-speaking area. OpenChargeMap imports government open data sources in several countries, but I'm not sure if all the imports are still being updated - and the quality of the crowdsourced data varies a lot by area.

Yes that's totally ok for the moment! Maybe in a "far future" we could imagine a translation feature to translate those text fields on the fly if the user requests it, but what this issue was about is just translating the app itself 👍

* The price comparison using Chargeprice only supports [four languages](https://github.com/chargeprice/chargeprice-api-docs/blob/master/api/enums.md) so far. So we need to fall back to English in other cases.

That's totally ok too, fall back to english in other cases is really sufficient for the moment!

* While I know a little bit of French and Scandinavian languages, I'm probably not able to review the correctness of technical terms in those translations or provide support in those languages.

I'm a native french speaker, so I can asure you that my french translations will be pretty correct and understandable by other french speaking people :) But I understand your concern and the difficulty of reviewing translations of other contributors in other languages. I know that https://github.com/CatimaLoyalty/Android is for example using community maintained translations, and it's working great so far :)

* Waiting for a couple of new strings to be translated before a new release might slow down the release process quite a bit. So I would probably not make translations other than English and German mandatory for release, rather let the app fall back to English if needed and include translations later once they are done.

That's totally ok too, and that's how it is done in Catima and it work's great! When changes are made, if the translations are made before the release by fast contributors it's great, but otherwise it just gets integrated later :)

* For the same reason, I would probably also not translate the changelogs for F-Droid or the Play Store to other languages

That's up to you, I know in Catima the changelogs get less attention by the contributors, but get integrated if completed. So these could get integrated if completed in other languages if you wish.

So when we add more translations I would suggest also adding a dialog that informs the user that they are using an "unofficial" translation with the caveats mentioned above. There's already a way to set the language within the app, so they can opt to use English or German instead of their system language if preferred.

Maybe an "unofficial" warning would be too much and weird for the user. I think it would be better to just integrate languages that are ready because their translation is well done and production ready. Having an "unofficial" tag might just confuse the user. The translation does not need to be perfect anyway and could get improved over time if needed :)

Do you already have experience with Weblate or other translation platforms and how easy it is to integrate Android XML strings files and to push and pull updates?

Yes I already integrated https://github.com/francoisfds/BikeSharingHub to Weblate and it was a really easy setup process :) All strings get detected automatically and kept up to date with the repo. When users make translations you can choose the way those are integrated back into the project, but one way for example is just for the Weblate bot to open PRs in this repo with the translation changes made :)

I hope my answers are helpful and again thanks for your detailed answers!

@johan12345
Copy link
Collaborator

I have now added EVMap to Weblate. Let's see how this goes :)

Note that I'm currently still in the trial period and the project still needs to be approved for free hosting for open source projects. But in principle it should already be possible to translate strings.

I think it would be better to just integrate languages that are ready because their translation is well done and production ready.

That is definitely a good idea. Do you know a good way how to handle this? I see that Weblate has already opened a PR (#211) with new translations, and I guess that PR will contain translations for all languages, so it wouldn't easily be possible to merge just changes to some of the languages...

@johan12345
Copy link
Collaborator

I see that @comradekingu has already started translating the first couple of strings into Norwegian. Thanks!

@Altonss
Copy link
Contributor Author

Altonss commented Aug 19, 2022

I have now added EVMap to Weblate. Let's see how this goes :)

That's great, thanks!

Note that I'm currently still in the trial period and the project still needs to be approved for free hosting for open source projects. But in principle it should already be possible to translate strings.

I think it would be better to just integrate languages that are ready because their translation is well done and production ready.

That is definitely a good idea. Do you know a good way how to handle this? I see that Weblate has already opened a PR (#211) with new translations, and I guess that PR will contain translations for all languages, so it wouldn't easily be possible to merge just changes to some of the languages...

I don't know if there is a way to do this, but hopefully there is a way to manage this in Weblate (maybe something like if this translation has reached a certain threshhold (>95%) and is approved by the owner, than a PR can be triggered?)

@johan12345
Copy link
Collaborator

@Altonss I now added more detailed context descriptions to the remaining few strings - I hope this helps!

I don't know if there is a way to do this, but hopefully there is a way to manage this in Weblate (maybe something like if this translation has reached a certain threshhold (>95%) and is approved by the owner, than a PR can be triggered?)

Hmm, didn't find anything like this so far. I guess I'll have to cherry-pick the commits for the respective languages then.

@johan12345
Copy link
Collaborator

Ah, there is at least a way to make Weblate squash all commits for one language. That makes it very easy to cherry-pick a single language, which I just did for the French translation 🎉

@johan12345
Copy link
Collaborator

johan12345 commented Aug 22, 2022

Oh, now Android Lint is complaining due to WeblateOrg/weblate#7520 :(
But for French this should be fixed with translate/translate#4679, which is included in yesterday's Weblate release 4.14... so let's see when it gets updated.

@Altonss
Copy link
Contributor Author

Altonss commented Aug 23, 2022

Ah, there is at least a way to make Weblate squash all commits for one language.

You could also just have weblate make one PR per language, I think it's a setting that is possible in the Weblate configuration panel :)

@johan12345
Copy link
Collaborator

That's what I was looking for, but I don't see any such option.

@comradekingu
Copy link
Contributor

comradekingu commented Aug 23, 2022

@johan12345
It is in the config for the squashing plugin
Something like https://hosted.weblate.org/addons/evmap/android/436/ ?

That said I have never experienced limiting translations artificially doing any good. I propose not doing it.
Smaller efforts scale into full coverage faster if people are able to browse the strings in the UI.

People notice something as incomplete is secondary to being able to understand the simpler strings at all for some.
In my head it means they will also feel like they can do something about it, which the UI can facilitate with a link to Weblate.
More people doing something means reaching the (virtual) cut-off earlier, and nobody is demotivated in not doing so.

The avenues where more people would notice are the bigger languages, and there translations are made available faster.
With smaller efforts people are happy to just have something.

I put in #218 to help smooth out the process of translating in the future.
Prior translations are not lost, and translators are generally very happy to find things improving.

@Altonss
Copy link
Contributor Author

Altonss commented Aug 23, 2022

That's what I was looking for, but I don't see any such option.

It is located in Evmap/Evmap > Manage > Add-ons and there you can find the setting normally :)

@johan12345
Copy link
Collaborator

johan12345 commented Aug 23, 2022

The squashing add-on has settings to squash commits (as the name says), which I have now configured as "per language". But nothing regarding separate PRs per language:
image

@Altonss
Copy link
Contributor Author

Altonss commented Aug 23, 2022

Also I saw that you are translating each language entry in the language setting in the selected language. I don't know if it's a good workflow. What I know from Catima and makes sense is to have each language name written in it's own language so that each user can find his language easily :)

@Altonss
Copy link
Contributor Author

Altonss commented Aug 23, 2022

The squashing add-on has settings to squash commits (as the name says), which I have now configured as "per language". But nothing regarding separate PRs per language: image

Ah I think I was wrong, there is only the sqash per language setting :(

@Altonss
Copy link
Contributor Author

Altonss commented Aug 23, 2022

@johan12345 It is in the config for the squashing plugin Something like https://hosted.weblate.org/addons/evmap/android/436/ ?

That said I have never experienced limiting translations artificially doing any good. I propose not doing it. Smaller efforts scale into full coverage faster if people are able to browse the strings in the UI.

People notice something as incomplete is secondary to being able to understand the simpler strings at all for some. In my head it means they will also feel like they can do something about it, which the UI can facilitate with a link to Weblate. More people doing something means reaching the (virtual) cut-off earlier, and nobody is demotivated in not doing so.

The avenues where more people would notice are the bigger languages, and there translations are made available faster. With smaller efforts people are happy to just have something.

I put in #218 to help smooth out the process of translating in the future. Prior translations are not lost, and translators are generally very happy to find things improving.

I agree with you that the fact to "limit" translation might not be the best way of doing, However I also understand @johan12345 who may encounter difficulties managing languages he does not understand and wants to be assured that the translations meet the standards he expect for the user experience... :)
So yes it's a difficult topic and agree with @comradekingu point, that the translation could be improved over time and the crowd will be a good control for the localisation: incremental changes might be a good way to progress :)

@johan12345
Copy link
Collaborator

johan12345 commented Aug 23, 2022

Yeah, let's see how it evolves. At least I want to have the possibility of merging translations for different languages separately if needed (e.g. if I know that someone is still actively working on a translation I would wait for them to finish before merging) - and that is doable as it's now set up with the squashing plugin.

This was referenced Aug 23, 2022
@johan12345
Copy link
Collaborator

The first update with French and Norwegian translations included is now on its way (Play Store release typically takes <1 day unless there are any issues in review, F-Droid release a couple more days until their build server picks it up). Let's close this issue and open other issues/PRs for any specific issues with translations.

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

No branches or pull requests

3 participants