Get started localization with Lokalise.co (FOLIO-1143)

[FOLIO-1296] Set up push of translated strings into GitHub repositories Created: 20/Jun/18  Updated: 12/Nov/18  Resolved: 24/Sep/18

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None
Parent: Get started localization with Lokalise.co

Type: Sub-task Priority: P3
Reporter: Peter Murray Assignee: Peter Murray
Resolution: Done Votes: 0
Labels: sprint45
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File screenshot-lokalise.co-2018.06.20-09-55-08.png    
Issue links:
Blocks
blocks UIIN-100 Extract hardcoded labels so they can ... Open
blocks UIU-416 Extract hardcoded labels so they can ... Closed
blocks STCOM-253 Extract all translatable texts into t... Closed
blocks STCOR-196 Extract translatable strings into tra... Closed
blocks UICHKIN-14 Extract hardcoded labels so they can ... Closed
blocks UITEN-15 Extract hardcoded labels so they can ... Closed
blocks UICIRC-49 Extract hardcoded labels so they can ... Blocked
blocks UISE-73 Extract hardcoded labels so they can ... Blocked
is blocked by FOLIO-1422 Change language setting causes wrong ... Closed
is blocked by FOLIO-1448 GitHub `bot` group access to some fol... Closed
is blocked by UIEH-543 folio-org/ui-eholdings GitHub configu... Closed
Relates
relates to FOLIO-1478 What to do about `en.json` translations Closed
Sprint:

 Description   

This is the other end of the GitHub integration ( FOLIO-1147 Closed ) – creating pull requests in GitHub that contain the translation strings from Lokalise.



 Comments   
Comment by Peter Murray [ 20/Jun/18 ]

Having problems getting this to work in Lokalise, and have contacted their support desk:

Conversation with Nick, CEO, 7:46 pm in Riga, Latvia

  • Peter: Hello everyone. We have a project (project ID: 768473125ada1bc8c67c66.19722909) with lots of GitHub repositories. We've successfully set up automatic pulls from GitHub to Lokalise, but we are having problems with the pushing of translation files from Lokalise to GitHub. Specifically, all of the language localization files are ending up in one repository rather than back into the multiple repositories where the strings came from.
    Lokalise typically replies in a few minutes.
  • Nick: Peter, sounds like a bug on our side. We will investigate and get back on this.
  • Peter: This is the pull request: https://github.com/folio-org/stripes-core/pull/329 ...and specifically the problem is here in the branch created by Lokalise: https://github.com/folio-org/stripes-core/tree/lokalise-2018-06-20_13-53-19/translations The only thing that should be in this directory is the `stripes-core` directory. The strings for `stripes-components` should be in the github.com/folio-org/stripes-components project, and so forth. This is the options I was using the 'Download' the strings with the GitHub trigger selected.
  • Nick: :thumbs_up:
  • Peter: Thoughts? This might not be an easy fix, so is there a place I should file an issue ticket?
  • Nick: Paul we are in Europe, office is closed. Will try to look into it tomorrow. I have set up a ticket for devs.
  • Nick: Sorry Peter
  • Nick: Okay, thanks! I'll wait for their reply. Have a good evening.
Comment by Cate Boerema (Inactive) [ 26/Jun/18 ]

Hi Peter Murray! The Translation Management Tool was slated for the Q2 release and, as I understand it from István Bender, this is the only remaining work needed to consider that complete. Any chance we can get this done this week so we can call it done?

Comment by Peter Murray [ 26/Jun/18 ]

Hi Cate Boerema. This turns out not to be as straight forward as initially thought. Lokalise asked us to put in a feature request for the ability to filter language files into specific GitHub repositories. In the meantime, István Bender suggested manually committing language file changes to the GitHub repositories. I will aim to get a script done this week that will do that.

Comment by Peter Murray [ 26/Jun/18 ]

On Jun 26, 2018, 2:06 AM -0500, Andrew from Lokalise <andrew@lokalise.co>, wrote:

Currently it is not supported to filter GitHub repositories to commit to (only by platform: iOS, Android, Web, Other). The only way I see it can be reached with multiple projects in Lokalise for each GitHub repository.

You can suggest this feature here: https://vote.lokalise.co, and we'll be happy to implement it as soon as there are some upvotes.

I created a feature request to have Lokalise do what we want.

Comment by István Bender [ 27/Jun/18 ]

Thanks Peter! I voted to the feature request and asked the colleagues to vote as well

Comment by István Bender [ 27/Jun/18 ]

Peter Murray Meantime Hungarian translation is 100% ready! It can be a test language for your script!

Comment by István Bender [ 10/Jul/18 ]

Peter Murray How are you going on with the script?

Comment by Peter Murray [ 14/Jul/18 ]

It is coming along. The Lokalise API description isn't as nice as I was hoping for, but I got data out of it now that replicates what I get from the web UI options. Finishing up the GitHub pieces now.

Comment by Peter Murray [ 16/Jul/18 ]

I have set up a script to work around the automatic Lokalise-pull-creation problem. The script is running with hard-coded config values, and it generates pull requests that look like this: https://github.com/folio-org/stripes-components/pull/493

Open questions:

  • Does this format of a pull request look okay?
  • What should happen with the pull request?
    1. Automatically merge it
    2. Automatically select reviewers
    3. Let it sit until someone deals with it manually

I'm leaning towards the first option because:

  • There is limited damage that can be done if a translation file with incorrect data is merged. If this is found to have happened, the data can be corrected in Lokalise and another automatic pull-request/merge put thought.
  • Who is going to review all of these translation string files? And what would be the criteria they would be used to review them?

Automated code merge processes make me nervous, but in this case – with this limited scope – I think it is okay. Thoughts?

Comment by Julian Ladisch [ 17/Jul/18 ]

Automatic merge is ok with me.

How does the script check that all translators have signed the Contributor License Agreement?
Does the script give all translators public recognition, for example by updating a file listing all contributors?

Comment by Peter Murray [ 17/Jul/18 ]

How does the script check that all translators have signed the Contributor License Agreement?

It doesn't, and that is a good point. The user account system on Lokalise is distinct from GitHub. The commits for all translated strings come from the 'folio-translations' account no matter who put them into Lokalise. Based on the inquiries I've seen so far, it is likely that we will have a bunch of people offering translations that don't have GitHub accounts. We will need to devise a mechanism to ensure they agree to the CLA terms without having to go through the CLA Assistant tied to a GitHub account.

Does the script give all translators public recognition, for example by updating a file listing all contributors?

This isn't possible through the API call I'm using now to export all strings. It looks like the user who contributed the string isn't available through the list-pairs-by-language API call either. I'll need to ask the Lokalise support contact if it is possible to get a list of contributors.

Comment by Peter Murray [ 17/Jul/18 ]

Query to Lokalise support:

For this open source project we want to do two things that are common to such projects. 1) Ask translators to acknowledge a Contributor License Agreement before adding translations; and 2) provide a way to get a list of translators to add to a CONTRIBUTORS.txt file. Are either of these possible given the current APIs?

Reply:

For the second one, we are planning to release API2.0 that will have total control over contributors. As for the first one, then there are no plans to do that, you need to implement this on your side. API 2.0 is coming in a month.

So I'll figure out a way to have translators acknowledge the CLA and wait for the API 2.0 to see if I can build a CONTRIBUTORS.txt file.

Comment by Peter Murray [ 21/Aug/18 ]

Recalling the last conversation with John Coburn. There are a number of situations where a key is appearing in more than one file (for example, `button.edit` is in both `stripes-components` and `stripes-core`). Lokalise deduplicates keys coming from multiple files, so `button.edit` will be exported in only one git repository's translations directory (`stripes-core` in this case because it is the one that is last imported into Lokalise).

The impact of this is unknown, so I'm going to modify the Lokalise-to-GitHub script to not replace `en.json` files (since the English files seem to be the most comprehensive). Then will run the script against all GitHub repositories to perform a single round trip from GitHub to Lokalise to GitHub.

Comment by Peter Murray [ 21/Aug/18 ]

Translation files update with these pull requests:

All were merged with the exception of folio-org/ui-organization, which had a jenkins/pr-merge failure.

Comment by István Bender [ 22/Aug/18 ]

We moved language files to translation/<modulename> folder in order to differetiate key collisions by file path. That's why we turned on "Include full path in the filenames" at the repository settings. Furthermore there is a setting at the pull option called "Differentiate keys by file". Perhaps we should turn it on as well to avoid deduplication.

Comment by Peter Murray [ 23/Aug/18 ]

Yes, that did the trick István Bender. Translation files updated with these pull requests:

Going to see how folio-snapshot looks overnight, then enable the automatic merging of pull requests coming from Lokalise.

Comment by Peter Murray [ 31/Aug/18 ]

Filed UIEH-543 Closed to track an issue with merging pull requests for translation strings into `ui-eholdings`. I'm going to run the Lokalise-to-GitHub script again and omit that repository.

Comment by Peter Murray [ 01/Sep/18 ]

Lokalise-to-GitHub run ran successfully to completion with all repositories but `ui-eholdings`.

Comment by Peter Murray [ 24/Sep/18 ]

UIEH-543 Closed addressed, so closing this blocker. These issues are no longer blocked by FOLIO-1296: STCOR-196 Closed , UICHKIN-14 Closed , UICIRC-49 Blocked , UIIN-100 Open , UITEN-15 Closed , UISE-73 Blocked , UIU-416 Closed .

Generated at Thu Feb 08 23:12:17 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.