Page MenuHomePhabricator

Improve Phabricator translation synchronization process
Closed, ResolvedPublic

Description

The current process must be improved. Issues:

  • The source string updates (which translatewiki.net sees) happen very rarely
    • This means there are huge amount of changes every time it happens. Importing thousands of changes puts stress on translatewiki.net and the translation admins who need to review all of it at once.
  • There seems to be only single person who knows how it works (@mmodell)
  • It is not clear how to get new languages enabled in our install
  • The process is not stable, for example message documentation flaps between having links and not having links: example.

I would like to see:

  • Regular updates of source strings (multiple times per year)
  • Documentation of the above, with multiple people being able to do it
  • Clear criteria and process for getting new languages enabled on Phabricator
  • Regular process of updating translation to our Phabricator instance
  • Documentation of the above, with multiple people being able to do it

Event Timeline

https://translatewiki.net/wiki/Translating:Phabricator says translations are updated every few weeks? Is this true? Is there any logging for people to see when it has happened=

@Nikerabbit: I merge changes from translatewiki when I do a phabricator deploy. This usually happens when there are enough upstream phabricator improvements to justify the time it takes to merge, review and deploy everything. Upstream development has been slow lately so there haven't been many changes that have motivated me to do a phabricator deploy. The upshot is that phabricator updates have been few and far between in recent months.

Here's an outline of the steps to add, update and deploy translations:

Language update process

Enabling a new language

  1. Add a new locale class in rPHTR /src/locales/
  2. Run generate.php
  3. Commit and deploy (see below)

Deploying updated translations from translatewiki.net

  1. Get the latest commits in the rPHTR translation repo
cd translations
git pull
  1. Update the generated translation classes. run ./generate.php from the repository root (ignore errors in the output) (Source is here: rPHTR /generate.php)
./generate.php
  1. review and commit the changes
  2. push changes back to origin
  3. Add the submodule updates to the parent repo (rPHDEP)
  4. Tag and Deploy rPHDEP

I think the only people who actually have enough access to do the deploy (besides myself) are the SRE team plus @brennen and maybe @thcipriani?

Brennen has paired with me on a deploy once or twice, however, more cross training wouldn't hurt.

Is there any chance of discussing this upstream so they can properly incorporate l10n in their repository?

@Nemo_bis: The upstream designed our current translation process but explicitly declined to accept the translations upstream. You could propose it over at https://discourse.phabricator-community.org/ and see if they have any renewed interest now that a fairly complete translation is available for some languages.

@mmodell How about the message documentation generation? I think it's causing the most issues by alternating between links and no links. If that can be avoided it would solve most of my complaints.

@Nikerabbit: I have really no idea why that happens but I will see what I can do...

@Nikerabbit: Ok I figured out the URLs... Would you prefer that I leave it alone or should I submit a diff that restores the URLs?

I doubt many people click those links, but on the other hand I think nobody will do anything with the unlinked file names, so actually the links would be preferable if we automatically generate message documentation at all.

@Nemo_bis: The upstream designed our current translation process but explicitly declined to accept the translations upstream.

But that was many years ago. Maybe in the meanwhile the developers have discovered that languages exist beyond English.