AtlasOfLivingAustralia/downloads-plugin

add properties to crowdin

Closed this issue · 20 comments

ansell commented

Thanks, it would be useful to improve our i18n with a service like crowdin. We will look into it.

vjrj commented

In fact, there is already a ALA project in crowdin for that,
https://crowdin.com/project/ala-i18n

For me, the missing part is the github integration to sync the ALA repo properties with crowdin automatically. And viceversa, ALA repos with translations, when ready. Something that nowadays is manual (via PRs, etc).
https://support.crowdin.com/github-integration/

This is what GBIF does I think, see commits of:
https://github.com/gbif-crowdin
cc @timrobertson100

So if you update some .properties, crowdin auto-update the ALA project with new messages to translate, and notify translators. And viceversa, when some translator (like Norwegian or Brazilian Portuguese that are now translating) do some changes, automatically are committed to some i18n branch and can be easily merged.

Well, this is what other translation software like weblate does, I'm not a crowdin expert.

Also this facilitate to identify which translation is related to which repo (I send many time just to identify where to put our translations, which ALA repo to patch and send PRs).

thanks @ansell !

ansell commented

GBIF seem to have setup that project using our name. You would need to work with GBIF as they seem to be the ones with those details.

  • 👍1
timrobertson100 commented
ansell commented

Thanks Tim for the background. It isn't essential that ALA are the ones managing it, just that we know how to set new projects up in it and enable the changes to be propagated into git.

vjrj commented

If I can help somehow in some task, just tell me...

Just some more comments about i18n current situation (please sorry for the extension):

Yesterday I discover that it seems that people does not have rights to make translations and they are doing just "Suggestions", check:
https://crowdin.com/project/ala-i18n/activity_stream
so their suggestions, I suppose, should be approved later. Because Traditional Chinese is 0% translated and same with Norwegian.

In other translation services I used in the past, the workflow is like this: translation is open for register & logged users (via Google, or github, etc). So sometimes someone start and finish some translation to some language without you, as maintainer, notice it, and their translations are auto committed to a github i18n branch via a hook:
https://docs.weblate.org/en/weblate-2.4/admin/continuous.html

Maybe people are doing forks just to translate and build localized ALA versions, something that IMHO we should avoid.

I think this also, because there are some old translation PRs without merge that suggest that people are doing forks just for that:
AtlasOfLivingAustralia/generic-hub#6
AtlasOfLivingAustralia/biocache-hubs#159

Thanks!

vjrj commented

I come back to this, sorry.

If someone gives me perms in crowdin (for now, I only can suggest translations), I can try to help.

Also, if in the mid-term we find that crowdin is costly for us (I don't know who is paying this), I can setup a weblate instance that is FLOSS (based in django) and make the software translations more agile.

timrobertson100 commented

@vjrj - you should have a manager invitation now. That gives you permission to do anything.

vjrj commented

Thanks @timrobertson100 ...

vjrj commented

To configure the github integration we have to give some access to crowdin.

For instance, if I use my github user:
https://imgur.com/a/YjzEtiC
I can request access (as you can see in the screenshot) but maybe it's better if @ansell or @djtfmartin configure this part here:
https://crowdin.com/project/ala-i18n/settings#integration
for ALA respos. What do you prefer?

Later I can link repositories and translations.

ansell commented

I linked my Github and Crowdin accounts and added myself to the ala-i18n project but don't have access to the settings to put the integration together.

vjrj commented

I've just changed your role @ansell.

We can start adding this repo & closing this bug, because I can imagine that the rest will not be straightforward (to link existing messages to their github repos).

Probably we have to add new translations linked to github & remove not linked messages (trying not to lost translations). I'll help here when integrated...

ansell commented

I added this repositories messages.properties file to a new folder named downloads-plugin. Not sure if that is the correct way to use it, but it looked like what happened for the other repositories files. Reopen this issue if that wasn't the right way to do it.

vjrj commented

If I'm not wrong this is the manual way to add translations, but I don't see the github integration here:
https://crowdin.com/project/ala-i18n/settings#integration
that do this automatically (when new message strings are added to code, or in the other direction, when translations are finished, they are pushed to some i18n branch, so can be easily merged).

vjrj commented

Sorry to bother you again @ansell et all.

In general, if you configure strings to translate in crowdin (or other translation tool) manually, you have to do it every time that the software changes. For instance, if the download plugin, in this case, is improved, with some new texts, etc, we have always to remember to update crowdin so, translators can do their job. Many times we don't remember to do this step, so people keep translating some no updated properties. If you configure something to translate, via github -> crowdin + integration, always the messages are in sync between crowdin and github. So translators are notified when new translations should be done, if a software repo is updated.

But the part that worries my more, is the other direction, the crowdin -> github integration. When some translation is done, people have to send a PR to github ALA repos with their translations, and this is not an easy step. I spend many time just to find the relation between crowdin translations and ALA repos & directory, to proper patch. At the end, translations are done but not integrated (for instance, someone did the Basque translation). With the github integration, crowdin sends the translations to each ALA repo i18n branch, and you have only to merge.

As a summary: If someone with ALA github perms configures the github integration in crowdin, I can help to configure this continuous integration properly.

I know that for English-speaking developers, these types of internationalization tasks are not always very fun. I like to use a metaphor to cheer me up when I have to do this kind of tasks: Imagine you are a writer and your book is being translated into a multitude of languages...

I'll try to contact you via slack and maybe we can do this together if some doubt arises. Thanks

vjrj commented

As I mentioned @ansell via slash I configured a LA fork temporally for testing.

It's quite simple, in fact, you only configure some mapping like: https://github.com/living-atlases/downloads-plugin/blob/master/crowdin.yml similar like IPT is configured https://github.com/gbif/ipt/blob/master/crowdin.yml . And also a translations branch where crowdin will put the translations.

So you translate something (we did the Spanish translation, and some other started the German by coincidence) and crowdin directly prepare the PR in that branch.

But sadly, I found that you can only integrate one github repo via crowdin. There is another integration option called "Github enterprise" and other integrations types...I'll study other options.

Thanks!

vjrj commented

I continued with the sync task of translations.

I contacted crowdin support about the github limitation and commented me:

You are totally right that only one repo can be connected to the project in Crowdin and probably CLI is one of the best ways to create a custom solution here

So I started with collectory crowdin-cli configuration:
AtlasOfLivingAustralia/collectory-plugin#152
and with this configurations I synced 15 languages.
AtlasOfLivingAustralia/collectory-plugin#153

I'll continue with the rest of repositories till we have github and crowdin synchronized and easy to update in both directions (documented in the crowdin.yml configuration).

In the future, we can integrate this process in a CI system, so, sync in both directions are done automatically.

vjrj commented

And after syncing this plugin:
#44

vjrj commented

Hi there @ansell @djtfmartin , I return to this issue and PRs.

Some national portal comment me today:

My question is depending on our translations - if I'd rerun ansiblew - would our translations files already be part of the installation? We have a festival on 27.9 presenting the atlas and I read the thread we already have - but I'm still not quite sure

Would be nice to merge the rest of PRs and to include in the build process the crowdin sync commands mentioned in the README. So new builds have the translations up-to-date automatically.

This (or some similar workflow) would improve the use of ALA by non-English portals. Permit me to repeat something I mentioned above:

I know that for English-speaking developers, these types of internationalization tasks are not always very fun. I like to use a metaphor to cheer me up when I have to do this kind of tasks: Imagine you are a writer and your book is being translated into a multitude of languages.

Thanks.

vjrj commented

thanks indeed @djtfmartin for the merges!