Bahmni Translations vs Product Releases

Software Bahmni
1

Continuing the discussion from Translating Bahmni:

Important point (thanks @vsingh and @bharatak):

The timeline of centrally-organized Bahmni releases, and community-driven Bahmni translations are different.

The Bahmni core team will be responsible for releasing the core software product, in English, on a regular schedule (~every 6 weeks). Releases will typically require some new translations, and translations will be done at different speeds by different community members.

This implies that:

  • releases won’t be fully translated until “later”
  • hopefully we can create the expectation that priority languages get incremental translations within a fixed time period after the release (but we’ll see!)
  • we need a tool to “update this installation with the latest translations”

(This is a bit of a placeholder post for further discussion of this idea, and report-back of decisions.)

2

Thanks @darius,

Bahmni team - I’ll let @cioan comment more and share whatever work he has done, but he did a quick spike on a few aspects of this recently:

  • Setting up a CI plan in our Bamboo that automates committing translations from Transifex back up to github (to our fork as a POC). Basically runs this script given an appropriate trigger:

rm -rf /tmp/endtb-config cd /tmp git clone GitHub - PIH/endtb-config: configurations for endTB project cd /tmp/endtb-config git pull tx pull -sf git config --global push.default matching git add . git commit -am ‘adding latest translations from transifex’ git push

As a broader point, this "pih-deployment github project encapsulates our evolving approach to scripting the various environments we want to set up, using the common Bahmni deployment tools, but allowing for variations for our given implementations. Feedback welcome! :slightly_smiling:

Mike

3

I discussed this with @bharatak https://talk.openmrs.org/users/bharatak, but I don’t know whether this really got discussed more broadly afterwards.

I am guessing the reason for committing transifex translations to github is to ensure that it becomes part of implementation config zip file (endTB in this case).

But I was thinking that there is another workflow which makes more sense to me and I always thought Transifex was designed to be used like that.

  1. After every Bahmni release, Bahmni pushes new English message keys to transifex.
  2. People provide/update translations in Transifex.
  3. End user environments (production, UAT etc), pull the translations from Transifex directly.

There is another issue, implementation specific config is best maintained in transifex as independent project than within Bahmni project itself, because the number of implementations will keep on growing and not all will use CIEL exclusively.

4

Thanks @vsingh. Personally I have still been pushing us to pull translations into a github repository periodically for the benefits that this platform provides - namely version control, and a history including the ability to see what has changed easily over time.

My personal experience with Transifex is that it is a good platform for managing teh translations, but that it is far too easy to decide to delete a project forever, it doesn’t have version control (to my knowledge), and it actually is configured to blow away all translations if the english message even slightly changes. So having this all backed up and versioned in github is a good thing, IMHO.

Mike

5

I like the idea of backup being in github. Also, that if I am transifex I would probably do that myself, till them we (OpenMRS/Bahmni) should do it.

From user standpoint, adding to transifex and pulling down from the there - will provide experience with least friction; compared to adding github/package in the middle of their process. So we could break this up into two separate process.

  • Backup process
  • User process
1 Like
6

+1 to this. (I agree with Mike that we shouldn’t trust Transifex for this, even if there’s another way that environments pull the latest translations.)

An inherent difficulty is that the transifex model doesn’t support branches/versions, so basically people are always translating in the “master” branch, and then applying these translations to earlier releases.

@bharatak and I were thinking that the dev team needs to adopt some conventions to work around this. For example if you are going to make a non-cosmetic change to any text displayed in the UI you need to create a new key for this. (Because it would be bad to change the text for an existing key and then apply this to past releases.)

I think that given the correct set of conventions, it doesn’t matter whether Transifex is pulling translations nightly (like it is now) or we push them on release (and I’d lean towards nightly in case translators want to start early). But we should verify once we have the conventions.

But yes, the environments need to pull translations directly (though we may want to pull from github, since Transifex doesn’t allow anonymous REST access). However as much as possible we want this to still work for an offline installation.

What we did with endTB is not the right model going forwards. I agree that single-implementation-specific overrides should not live in the same Bahmni project under OpenMRS.

1 Like