Test linking of translation (.po) files with CrowdIn

[kcopas]

Much as I like the UI/UX of po4edit, I think we should seriously consider continuing our translation work via CrowdIn—most of our translators already know it and have used it. Better not to introduce yet another tool or platform unless there's good reason to.

Important to see whether and how CrowdIn works on paragraph-based strings—similar uses in the past proved difficult to manage, but maybe it was simply sub-optimal project configuration.

Could I please have some help? I think the steps go something like:

• [x] Have @timrobertson100 set up a CrowdIn project, probably called 'Nodes Guide'
• [x] Some combo of @MattBlissett and @MortenHofft setting up a CrowdIn-GitHub integration, probably (possibly?) mirroring that used for our CrowdIn project called GBIF.org
• [x] Establish appropriate links to the existing French, Portuguese and Spanish po files in /translations
• [x] Review and testing—ground-truthing, really—by y.t., @dnoesgaard @akristensen & @melianieraymond
• [x] Ensure that [approved] translations appear as expected across the HTML version of the documents
• [x] Invite FR, PT & ES translators to the project to update existing translations of Establishing an Effective GBIF Participant Node: Concepts and general considerations

I have an open thread with CrowdIn support on the topic. Specific documentation on dynamic integration with po files is, at best, po'.

[MattBlissett]

This is now ready for testing by @kcopas and team: https://crwd.in/gbif-nodes-guidance

Crowdin has imported the POT file, but has lost the obsolete translations -- the PO files contained the old translation string ("Node manage") as well as the new string ("Node manager") and the old translation ("Gestionnaire de nodal"), as in https://github.com/gbif/doc-effective-nodes-guidance/pull/21/files#diff-334efe037f8ee2f2bdfaac10ba0e48e0L406

Otherwise, I think it's OK, and (probably) if the document had been in Crowdin before these edits were made, Crowdin's own "memory" would have tracked the change.

[kcopas]

Looks awesome, still, at a glance—will have a closer look later tonight and see about shipping it out for updates.

[MattBlissett]

Something to test or think about is how the workflow would work for edits made in CrowdIn, and other edits made with PoEdit.

[kcopas]

I think I meant to send this and didn't manage to.

CrowdIn support wrote back with this suggestion, regarding the 'lost' older translations:

For such cases, you may use the update_option parameter in the configuration file (crowdin.yml) to keep the translations in Crowdin for the strings which you modified on your repo.

You may check the additional information on the matter here: https://support.crowdin.com/configuration-file/#changed-strings-update

Could you see whether this will work? If so, Morten will probably want to change the config in the GBIF.org UI project...thx

[kcopas]

I'm so close to trying this myself, but I feel confident I'll &#¢& it up.

Changed Strings Update

The parameter update_option is optional. If it is not set, translations for changed strings will be lost. Useful for typo fixes and minor changes in source strings.

Depending on the value, update_option is used to preserve translations and preserve/remove validations of changed strings during file update.

The values are:

• update_as_unapproved - preserve translations of changed strings and remove validations of those translations if they exist
• update_without_changes - preserve translations and validations of changed strings

Example of the configuration file with update_option parameter:

"project_identifier": "your-project-identifier"
"api_key": "54e01e81--your-api-key--f6a2724a"           #can be found in your project settings page
"base_path": "/home/office/source-code"

"files" : [
  {
    "source" : "/*.csv",
    "translation" : "/%three_letters_code%/%file_name%.csv",
    "first_line_contains_header" : true,
    "scheme" : "identifier,source_phrase,translation,context",
    "update_option" : "update_as_unapproved"
  },
  {
    "source": "/**/*.xlsx",
    "translation" : "/%three_letters_code%/folder/%file_name%.xlsx",
    "update_option" : "update_without_changes"
  }
]

[MattBlissett]

Probably the change https://github.com/gbif/doc-effective-nodes-guidance/commit/da42aebcf0dd8a4b50c97788c30c921bdcbaf4aa implements this. Would you like to test that it behaves as expected?

[kcopas]

Hmmm—I don't think so.

I was expecting to see the previous string somehow, but it doesn't seem to carry through. Here's a simple example—the updated DOI from the colophon.

Poedit flags this as 'needs work' but includes the old DOI as the current translation (see top line of screenshot):

But nothing from the previous string seems to persist in CrowdIn:

[kcopas]

Looks like you've got it going now @MattBlissett —thanks!

[MattBlissett]

At first I was expecting to see the old text retained in the .po file, but this is not the case: https://github.com/gbif/doc-effective-nodes-guidance/commit/7f789f63aa1667864a078277eea52e89433c8a36

I think CrowdIn probably doesn't use that possibility in the .po file, since most other translation files (like the Javascript one we use for the website) don't have a way to keep the "memory" within the file. Therefore, it's probably best if each document either uses 100% CrowdIn, or 100% native PO-file editing tools.

[kcopas]

Therefore, it's probably best if each document either uses 100% CrowdIn, or 100% native PO-file editing tools.

Agreed on this point—and I think it will be CrowdIn, at least on documents for which we want community assistance.