search

urbandroid-team / dont-kill-my-app

Android vendors, don't kill my app!
Creative Commons Attribution 4.0 International
1.25k stars 2.68k forks source link

Localization #19

Open yccheok opened 5 years ago

yccheok commented 5 years ago

As, this site info is helpful for non English speaker. It is good if translator can participate to translate this site as well.

I can contribute to translate the info to simplified Chinese and traditional Chinese. I think the major obstacle is that, I don't know how to translate UI text, for respective device. (Unless we have access to those device)

Artaud commented 5 years ago

Don't want to sound rude, but wouldn't Google Translate be enough? Just as you say, the major issue is that we don't have access to those devices and frankly, I assume the site will be updated often and translations would always be lagging behind.

yccheok commented 5 years ago

Yes. I know the issue, and me neither have any solution.

Regarding Google Translate, its quality is still hardly on-par with human translator. I use it as a tool to help me quickly understand a foreign language article. But, if I want to produce some content for end users (For instance, producing text for Google Play store description, text used in screenshots, text in Android app), I will ask help from human. I can hardly happy with the quality from Google Translate.

ol-v-er commented 5 years ago

English should be enough for Android developers and advanced users. However, if the maintainer accept this issue, I can do it in french. Maintaining the translation will be an issue...

alamos-gmbh commented 5 years ago

Implemented the API, already got contacted by a user if this information was available in German. I'd be happy to provide German translations if it becomes possible to include translations. Should be separate files, though, otherwise the API response become too big. (URL parameter, maybe?)

I think the user_solution part would be enough, the rest can remain English.

Also contacted you via email with the same information.

Artaud commented 5 years ago

Hi everyone, I'm sorry but I'll close this issue as I think it really really unrealistic to ever maintain any translation. This project is probably not going to freeze anytime soon so translation is a sisyfic job...

Trumeet commented 4 years ago

Any considerations now? This project is really helpful for Chinese developers, who have the major audience of Chinese vendors.

Artaud commented 4 years ago

The main issue is still keeping any changes in sync after a change in the source language. So - I'm trying to think of a solution here.... I'm still strongly opposed against manual translations. For visitors of the site, if they use Chrome, they can get a translated version easily. However adding a Google Translate icon to the top bar might be a good idea?

More important issue is translating the API. I'm thinking we could set up a CI task that would take the JSON files that the API serves and run them through Google Translate again. What do you think about that? Would you be able to do that @thubalek for example?

Trumeet commented 4 years ago

The main issue is still keeping any changes in sync after a change in the source language. So - I'm trying to think of a solution here.... I'm still strongly opposed against manual translations. For visitors of the site, if they use Chrome, they can get a translated version easily. However adding a Google Translate icon to the top bar might be a good idea?

More important issue is translating the API. I'm thinking we could set up a CI task that would take the JSON files that the API serves and run them through Google Translate again. What do you think about that? Would you be able to do that @thubalek for example?

Using Google translate may not be a good idea for some situations, for example:

thubalek commented 4 years ago

If make an agreement I can implement it. Later today I'll look at the API.

Artaud commented 4 years ago

Right, so let's start with translating the API. What we need to achieve is having the current files that reside at /api/v2/[vendor].json appear translated at /api/v2/[lang_code]/[vendor].json

After a quick look I can see a few caveats in achieving this regarding how the project is currently set up.

  1. The v2 API json files are generated on build by Github Pages engine, meaning we don't have access to the final JSON in commit time.
  2. The JSON files are generated through the _layouts/api.json template, as a Jekyll collection (defined in _config.yml). A simple way to get translations would be to declare a new collection for each language, and throw together a custom Liquid translate filter that would use the Google Translate API to output the JSON translated. However on Github Pages we cannot use custom plugins. So this could be only achieved if we opted out of Github Pages build engine and build the pages through our own CI solution (and mind me, that would be really great for other reasons as well).

I'm definitely open to other ideas...

fennifith commented 4 years ago

I'm opposed to automating the translations of this material as it will have a noticeable effect on the quality and usability of the resulting text, and could change the meaning unintentionally; Google Translate is not often used for translating technical/software instructions.

As for maintenance, I'd like to point out that I, a sole developer and full-time college student, maintain multiple localized translations (the values-<locale>/ dirs) in nearly all of my Android apps. Granted, I rely almost entirely on pull requests to keep them up to date, but it is not overly difficult to keep track of - though I have been taking a bit of a reprieve as of late to focus on classes. They might not be of the same influence or scope, but they are definitely significant in quantity - and I think the influence of this repository functions as an argument for creating translations, if anything. Regardless of whether they are entirely up to date, having any translations at all is better than nothing. There are people offering to donate their time to make this project useful to other people, and on principle I don't like turning those contributions away.

Sorry for the mini-rant. Back to technicalities: A workflow here could be as simple as creating an issue whenever a change is made to the original file, and tracking its progress until it eventually propagates to all of its translated versions. (maybe writing an issue template with all of the locales listed as check boxes could make this easier?)

As for the viability of implementing this on the current Jekyll structure - looking at this blog post as an example, it definitely seems possible to achieve this without using a custom plugin, and that would make it open to manual contributions as well. Here is what I would propose changing:

This should create the translated files in, for example, /zh/huawei, while leaving the untranslated files in the same place. The one caveat is that the same will have to apply to the API; the en locale will be an exception to the .../<lang>/<vendor>.json pattern, and will appear at .../<vendor>.json instead. This has a good side, though, as it means the current files will stay in the same place, so any projects currently implementing the API will not need to make any changes.

I am definitely willing to create a PR to implement this, with approval.

fqborges commented 4 years ago

@fennifith thought I do not fully understand the details, it seems to be a good solution. I am just wondering how much work would be needed to keep translations in sync.

For example, I used to translate contents for a game using gettext, that maps the original strings to the translated strings, making easy to track changes, updates needed and completion. Having this would be a must, for community driven translation.

thubalek commented 4 years ago

There is definitely problem if sync if translation manual. If you change original text then you have to notify translator for all languages and make sure they translated text.

I'm afraid this will be hard to implement just using GitHub infrastructure. This is usually implemented in translation web apps like https://www.oneskyapp.com/, https://crowdin.com/ or https://phrase.com/

fennifith commented 4 years ago

@thubalek

There is definitely problem if sync if translation manual. If you change original text then you have to notify translator for all languages and make sure they translated text.

I don't entirely see why this is a problem; assuming all contributions are looked over before being merged, all you should need to do is check the last modified date of the translated files to see if they're out of date. I don't see why it's necessary to explicitly notify translators of a change - if someone has made a contribution, they shouldn't be expected to maintain their work indefinitely. Any other contributor could easily take over and help keep them up to date. Opening an issue as soon as the translations are made out of date should make it possible to publicly track which sections of the site need translating (thus the suggestion of an issue template). Perhaps assigning a label could make it easier for contributors to filter these issues from the rest? You could even automate this process with a git hook or github actions if you really see the need.

If there is really a need to use a web app for this, I've heard of success with using OneSky, but I don't see how proxying contributions through a third-party interface could possibly reduce the amount of maintenance work compared to accepting contributions directly into the repository.

thubalek commented 4 years ago

Lets imagine scenario when we have document for Nokia. We have volunteer that will translate it from English into (e.g.) Catalan. Everything is fine.

Then we update that document adding new section. Our volunteer is no longer available and there is no other volunteer for this language.

What we will do? Will we stay outdated for Catalan? Will we remove Catalan translation until some other volunteer submits update?

I have many years experience with I18N of my apps and it is always very difficult to find volunteers for exotic languages and keep those translations up to date with default translation. Most of those translations ends in half translated state which does not look good.

And maintenance of android translations is easier as strings are mostly one or two sentences and you can compare current original with original from the time of translation. It is even harder to track changes for free form translations.

To overcome this issue it is necessary to have automated system of begging for help as you can have easily 15 or 20 translations to maintain (I have 32 languages for Battery Widget Reborn, between 10 and 20 for my other apps)

Artaud commented 4 years ago

Thanks a lot for the discussion.

I agree with @thubalek that maintenance of translations is very hard and would need a very dedicated manager around. I believe that while we all appreciate the impact of DKMA, there's no one here who could dedicate a significant portion of his time to it.

I also agree that machine translated texts are a poor man's solution. At the same time, I don't want to turn away people who actually offered their time to the translation. We were thinking about this a little more and @petrnalevka came up with two different possible solutions.

  1. Forking the repo For each translation, the translator could fork this whole repository and set up a new Github Page with the fork. From the main site, we would redirect a subdomain (e.g. de.dontkillmyapp.com) to this fork. All translators for the given language would then gather around that fork.

This way has multiple pros:

Keeping the site in sync with the upstream DKMA would mean just doing a git pull once in a while.

  1. Using GitLocalize I just found this tool that not only serves as a web translation framework but works directly on top of Github and seems to be able to track changes in the source language (English) and compare them to the translation. Thus showing the parts that need translation. It will create a new folder for each language, so that will also take care of the JSON API files generation. Seems to be the tool for the job, whaddaya think?
Artaud commented 4 years ago

Anybody voting for GitLocalize? To me it sounds really cool, simpler and more powerful than everything that we came up with before.

ubuntudroid commented 4 years ago

What about weblate? Never used it with a web project, but in our company we have a very well working setup for our mobile apps. You can also easily keep it in sync with your repository, just as GitLocalize, and they have a polished UI for doing translations. They have outstanding support and it is free for open source projects. I'm not affiliated with them, just a very happy user. ;)

On a related note: I can help with German translation.

Artaud commented 4 years ago

@ubuntudroid I've chosen GitLocalize. It doesn't have as polished interface but it is a lot easier to setup and it seems to me that Weblate is really well suited for short strings, whereas what we have is a big chunk of text that's hard to break up. I'm going to setup GitLocalize now and invite all the people who offered to help with translations.

Artaud commented 4 years ago

@ubuntudroid @yccheok @ol-v-er @alamos-gmbh @Trumeet To everyone who offered to help with translations:

I have set up GitLocalize for this repo. If you still want to help with the translation, please sign in to GitLocalize at https://gitlocalize.com/ and let me know either here or at jiri.richter@urbandroid.org - I'll add you to the project.

How to translate: At https://gitlocalize.com/repo/3613 you can see a list of languages. If your language is missing, let me know and I'll add it (not sure what access level is needed for that).

Tapping on the language takes you to a file picker. Go to _vendors folder, then select the *.md file you want to translate. Tapping on it takes you to an editor. In the right column, you'll see several fields. What we want to translate is explanation, user_solution and developer_solution. (They don't all have to be there). Please don't touch the other fields.

After the translation, click on "Create review request" and I'll review it and merge into the repo.

Thanks a lot for everyone involved in the discussion and especially to any potential translators!

TCattd commented 4 years ago

@Artaud thanks :)

Just registered at GitLocalize. Can help with Spanish here. Same username as here.

Artaud commented 4 years ago

@TCattd Perfect, thank you! I've added you to the project.

fqborges commented 4 years ago

@Artaud Thanks!

Please add me @fqborges, lang: pt-br (Portuguese (Brazil))

Artaud commented 4 years ago

Added @fqborges !

rzetzsche commented 4 years ago

I would be happy to help with a translation to German. @Artaud

KovalevArtem commented 4 years ago

I suggest using the Weblate platform too. It's completely free for open source projects. I will be happy to help with translation into Russian.

lreyn commented 4 years ago

Hi @Artaud - could you add:

we can help with the Spanish translations as well.

mlscherer commented 3 years ago

Hi, please add be as pt-br - Portuguese (Brazil) contributor

@mlscherer

rzetzsche commented 3 years ago

@Artaud Is this still something you want to have? It looks pretty stale but I think it is a pretty useful enhancement. I would love to translate some parts of the website.

golshani-mhd commented 3 years ago

Great work @Artaud, I would be happy to be the translator of the Persian language (language-code: 'fa-IR' or 'fa'). Please add me @golshani-mhd too.

mantaroh commented 3 years ago

Hi @Artaud

Could you please add @mantaroh ? I'd like to add the Japanese (ja-jp) translation.

and3rson commented 3 years ago

@Artaud I'm willing to help with Ukrainian translation. Same username as here (@and3rson). Thanks in advance!

P.S. Is the main page translatable as well?