Three branches are killing the translation workflow, how to deal with that?

(Erick Guan) #1

I manage to keep Discourse translation for Chinese shining recently. But it’s super annoying to keep the translation up to date when you upgrade to the new version.

I can’t promise the translation on stable is stable. It hurts. The problem is because Transifex is catching with master. But it’s not easy to put them back on the old branch since the old string may be deleted on Transifex.

Manually updating translation is a work around but it’s not quite right. Any thoughts? Does Transifex provide anything for that? Or build the script to deal with that?

Admin UI for translations
(Gerhard Schlager) #2

I’ve also been thinking about this the past few days.
It would be nice if Transifex supported different versions, but it doesn’t look like that’s possible at the moment.

Looking at other open source projects that use Transifex I’ve found only one (concrete5) that uses it to translate multiple versions. They’ve developed a tool (tx2tx) to help synchronize different versions of translations.

Maybe we could do something like that?

(Dave McClure) #3

Won’t this problem kind of go away once the next real stable release is made? By that time, if the translations are up to date, they’ll stay that way on stable.

You’ll have to keep up with new things added to master, but those won’t roll out into stable until later, so it should work out pretty well.

One thing that would help is for the team to give folks a heads up when we are 1-2 weeks away from the next stable release so translators and plug-in authors to do a final push to make sure things are good to go before it gets rolled out.

Sam mentioned something similar here, though he didn’t specifically talk about translations.

(Erick Guan) #4

It’s not true. Even if I kept updating translations, we would still change strings for any reasons. Then it will break.

It seems current translation for stable didn’t update? Though the translation is 100%. We only backport some commits to stable, is that right? If so, this will still be a problem.


(Dave McClure) #5

The plan is that a new stable release is made every 8 weeks.

So in another 4-5 weeks, everything that changes in master will get merged into stable, including all the updates to the translations made since the last release.

This doesn’t require backporting anything.

However, if many strings are left untranslated when that next release is made, they will stay that way for another 8 weeks. (Fixing that in the interim period would require backporting changes, which may be difficult for the reasons you mention).

So my advice remains:

  1. Keep things up to date on master
  2. Review the translations for completeness in the 1-2 weeks before each next stable release.
  3. The team should be aware of this and help translators by:
    • communicating the expected release date of the next stable release in advance by 1-2 weeks
    • trying not to make/accept major changes to translation strings in those 1-2 weeks prior to each stable release

The quote I pulled above from @sam’s post on the post v1 release schedule mentions a similar approach to helping plugin authors make sure their extensions are in working order prior to each stable release.

I think @techapj has been responsible for pulling in translation updates recently so he may have some insights here as well.