mozilla-l10n/fx-private-relay-l10n

Migration of localized strings in Pontoon due to adding TOML file

Closed this issue · 5 comments

This is filed due to this PR with regional specific content to be localized.

  • Once pontoon.toml file is added, the repo path will change as a result, which will break the current build.
  • This change requires migration of localized strings to the new path. This will result in losing metadata of localization contribution details, including timestamps.
  • To keep the metadata, pontoon has a workaround, and will coordinate with the Relay team to make it happen.

@mathjazz @Vinnl @maxxcrawford

Vinnl commented

Unfortunately I'm not sure yet exactly of what will be going wrong, but just to clarify in case it's relevant: apart from the brand strings (which I'll deduplicate as soon as I know how), all of the strings in the new phones.ftl and bundle.ftl are new to this repository, i.e. they're not moved from app.ftl. So those strings have not been localised before, and should not have contribution details yet.

Would be interested to hear how the repo path will change, and if we can prevent/mitigate that.

Sorry for the delay. Seems like my #mozflu is finally winding down...

I don't think the statements in the original post are accurate, so I'll explain what changes are needed and why for Pontoon to work properly with the new setup.


Pontoon can detect localizable files in the repository in tho ways:

  1. Automatically, which requires the repo to follow specific folder structure rules. (used ATM)
  2. Using the TOML configuration file, which allows for more flexibility, including localizing different files to different locales. (used once #103 will be merged)

While the automatic file detection strategy uses relative file paths to represent files internally (e.g. app.ftl), the TOML configuration file strategy uses absolute paths (e.g. en/app.ftl). That is by design.

Switching from one strategy to another will result in existing strings to be imported from repository as new strings once #103 will be merged, because their unique identifiers (part of which is the file path) will change.

Strings are imported from VCS without metadata, which means attributions and timestamps will be lost if we simply merge the PR. To mitigate that, we need to modify the paths in Pontoon DB just before merging #103.

Want to add the process stated by Matjaž in a private chat:

In practice the migration will look like this:

  • Stop Pontoon sync.
  • Merge the PR.
  • Do the migration in Pontoon DB (rename the app.ftl file and migrate brand.ftl translations).
  • Restart Pontoon sync.
Vinnl commented

Gotcha @mathjazz, that all makes sense, and glad to hear your mozflu is calming down.

I wish now we'd have started with the TOML file initially :) So sounds like either:

  1. We schedule a call to do the migration together.
  2. You perform the steps Peiying described above whenever it suits you, including merging #103.

I'd be fine with either option. I'll schedule a meeting to do the former (I heard you're in my timezone); feel free to reschedule or reject if you'd rather go for the latter option.

With #103 merged and Pontoon migration complete, I think we can close this issue.

Please let me know if you notice any issues.