Silverstripe-framework: RFC Shift i18n textcollection from release to travis cron

[tractorcow]

As a part of our release process we perform this normal task:

• Run text collector on each module
• Merge all strings into master
• Push up master strings to transifex
• Pull down all localised strings

This process is kind of slow, and is normally a fragile part of the releases. If there's a bug / problem in localisations they tend not to manifest themselves until release.

My proposal is:

Option 1

• Shift text collector to a travis task: The form of this task will be very similar to composer run-script lint and composer run-script lint-clean, i.e. pre-configured and robust. The task should collect strings for the root module, running textcollector, and automatically updating the master en.yml.
• The regular human-run release process still pushes master and pulls updated strings from transifex, but does not run text-collector.

This option is the hardest to implement, since we need to provide write permissions to travis and setup a cron for each repo.

Option 2

An optional variant of the above process is to make text collector a task that's run on pull requests, which would require contributors to update en.yml if they add any localised keys.

Instead of running as a cron, we would run text collector on all pull requests. If it detected any uncommitted changes to en.yml it would fail the PR.

This option is the easiest to implement.

[robbieaverill]

I'm a big fan of option 2 here, but it doesn't necessarily mean that devs should pull non-default language translations too. Perhaps we could implement option 2 to start with, but I think that there needs to be a cron task somewhere that both (a) pushes the source file to Transifex and (b) pulls non-source translations on a regular basis.

[tractorcow]

Dev's wont need to pull localisations, just make sure they update their master string.

E.g. if they add a new _t() call, they'll need to update en.yml as well.

Anything transifex related would remain a cow-only job.

[robbieaverill]

I see. In that case I vote for option 2 - a Travis build step for ensuring the text collector returns a zero exit code (ideally, but that'd mean we'd have to fix it 😆 ) or just run it piped to dev/null then check lang/en.yml is unchanged

[dhensby]

agree with @robbieaverill on this. option 2

[TheBnl]

Don't know if it really is related to this issue tread, but i found some translatable strings that are not yet available on Transifex. It concerns the DBDate field type, see below:

SilverStripe\ORM\FieldType\DBDate:
  SECONDS_SHORT_PLURALS: '{count} seconde|{count} seconden'
  MINUTES_SHORT_PLURALS': '{count} minuut|{count} minuten'
  HOURS_SHORT_PLURALS: '{count} uur|{count} uur'
  DAYS_SHORT_PLURALS: '{count} dag|{count} dagen'
  MONTHS_SHORT_PLURALS': '{count} maand|{count} maanden'
  YEARS_SHORT_PLURALS': '{count} jaar|{count} jaren'

I've you guys can give me an heads up when the strings are available for translation i could make some time to look into it! 👍

edit:
I see the strings are in the master file in git but not yet updated on Transifex

[robbieaverill]

@TheBnl I've just pushed the latest source file to Transifex, hopefully you can translate them now

[robbieaverill]

Ping @silverstripe/core-team for a final vote. Current status: 3 votes in favour (@tractorcow @dhensby and myself), none against.

[maxime-rainville]

I'm in favour. Most of my dev set up are in French, and it's kind of crazy how patchy the translations are. I try to fix some of them, but it's confusing because some of the strings are not in Transifex yet or difficult to find.

[robbieaverill]

Cool, seems like we're good for this then. I think it'll make translations more of a first class citizen in our development process rather than an afterthought during releases too (at least for the pushing English source files up part anyway).

Accepted with @tractorcow @dhensby @robbieaverill @maxime-rainville and @stevie-mayhew in favour.

[robbieaverill]

Actually, we didn't decide on option 1 or option 2. Option 1 would require giving write access to an account that Travis can authenticate as, option 2 wouldn't and would be more of a linting check