@sgiehl opened this Issue on August 20th 2021 Member

We used to use Transifex for our translation management, but decided to move on to Weblate in the future.
This issue is about to gather and keep track on the tasks we need to do in order to finish the Migration

@Findus23 commented on August 20th 2021 Member

Freeze all resources on Transifex so no new translations can be added on a specific day

Do you know if there is an easy way to do this? (So that editing is disabled for everyone) Or do we need to do an announcement, wait as long as possible and then just ignore everything afterwards?

@sgiehl commented on August 20th 2021 Member

It's possible to disable that for each resource on Transifex in the settings
I would maybe aim to disable that by end of next week and post an announcement early next week, that we will do that in order to migrate to weblate

@Findus23 commented on August 20th 2021 Member

Regarding enabled features we can take a look at https://docs.weblate.org/en/latest/workflows.html:

I think there would be two possibilities:

same as before (review)

  • Enable reviews: on
  • Enable suggestions: on
  • Suggestion voting: off

This way, people can translate and (possibly a separate group of users?) can review those strings. Nevertheless both reviewed and unreviewed strings would be used in Matomo.

Migrating existing review status is not impossible using both APIs, but seems like a lot of work.

Voting

I have seen this method work in quite a few FOSS projects before:

  • Enable reviews: off
  • Enable suggestions: on
  • Suggestion voting: on
  • Autoaccept suggestions: 1

This means that again anyone with an account can edit the translation (and if there wasn't one before, it is used immediately), but if two people disagree on which translation to use, both can be created as suggestions and everyone can vote on the better translation.

Other settings:

Project wide:

Access:

I would stay with "Public" (except for the premium-plugins): This allows anyone (without an account) to see the translation strings and suggest changes. Anyone with an account on hosted.weblate.org can edit translations.

Workflow:
  • Use shared translation memory: This means that the translation memory (which suggests translations that were already made) is shared with other projects on hosted.weblate.org. I'd tend to enable this as the translations are already public and on the contrary it makes translating simple strings that already exist in other software easier for translators.
  • Enable reviews: see above
  • Enable source reviews: I think we could enable this independently from the above. This way people could spellcheck or check for legibility of the original and then mark them as reviewed.
  • Allow editing source strings (I can't find the setting any more): I would disable this as it makes the PRs harder to merge if they change UI tests. If someone notices an issue in the English text they can easily create a comment about it and someone can then create a normal PR on Github to fix it.

Per Component settings:

Basic/Translation
  • Priority: Will be copied over from existing ones
  • Turn on suggestions: I'd always keep this one enabled
  • Suggestion voting: see above
  • Allow translation propagation: If I understand this correctly, it doesn't matter as Matomo uses IDs for the strings and no two translations have the same ID (even if they have the same text, which shouldn't happen)

    It’s usually a good idea to turn this off for monolingual translations, unless you are using the same IDs across the whole project.

  • Manage strings: I'd disable this as I could think of no reason to add a new translation string from Weblate
  • Translation flags:

    • php-format: So that the printf strings are properly detected (both in the UI and to enable the corresponding checks)
    • ignore-optional-plural: This check marks source strings that could be improved by adding pluralisation. As Matomo's translation system doesn't support pluralisation, this is not helpful
  • Push on commit: I'd disable this as it means that every time weblate converts all changes to commits (every few hours), this will be pushed to the Matomo PR and trigger a CI run. Instead maybe we should manually trigger pushes every time we want to update strings (or find a way to weekly push changes)

  • Adding new translation: I'm not sure what the best way to add a new language is. "Contact Maintainers" is ideal if we want to confirm a language before someone adds it. Either way adding a language in Weblate automatically creates the correct new languagecode.json file in the repo.
    Then again, adding a language seems to work on a per-component level. Which means that if a new plugin is added to Matomo, every translator needs to add their language again.
@Findus23 commented on August 20th 2021 Member

Glossary

I think the glossary is quite important to keep things consistent. Thankfully the glossary in Weblate seems to be quite user friendly and especially is its own component so that all features work on glossary strings.

The existing entries in all languages can be exported as a CSV from here:
https://www.transifex.com/matomo/matomo/glossary/de/

One could write a simple program to convert those, but I can't find a way to upload translation files in transifex. Maybe this is something we could ask the support.

@sgiehl commented on August 20th 2021 Member

Push on commit: I'd disable this as it means that every time weblate converts all changes to commits (every few hours), this will be pushed to the Matomo PR and trigger a CI run. Instead maybe we should manually trigger pushes every time we want to update strings (or find a way to weekly push changes)

Sounds fine. Maybe there is a possibility to trigger this through API? If so we could use a simple GitHub action to trigger it

@Findus23 commented on August 20th 2021 Member

I think a wlc push with https://docs.weblate.org/en/latest/wlc.html should do exactly this

@sgiehl commented on August 20th 2021 Member

Feel free to enable the push on commit then.

Regarding the translation workflow: I'm tempted to go with the voting model as you suggested

This Issue was closed on September 23rd 2021
Powered by GitHub Issue Mirror