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.)
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!
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
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.
After every Bahmni release, Bahmni pushes new English message keys to
People provide/update translations in Transifex.
End user environments (production, UAT etc), pull the translations from
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.
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.
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.
+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.