Using placeholders is going to be required to get high quality translations. With a bit of documentation, translators should be able to handle them. Failing that, they can translate the majority of strings; most strings will probably not include substitutions.
Here’s the translation guidelines for Gnome and KDE. The tools they use are probably not applicable to our project, but the features of their tools might be able to guide the development of ours.
Since translatable strings are part of the source code, they tend to be nearly as volatile. However, “borrowing” gettext’s method of tracking translatable strings and marking/preserving “fuzzy” translations would reduce this significantly.
IMO, xl() should operate very similar to gettext() / i18n() except drawing data from the database instead of files / message catalogs / etc. I’m not aware of how Brady is extracting translatable string from the source code and putting them in the spreadsheet, but if it is by scanning the source code, introducing a XL_NOOP that is recognized by the source code scanner, but does not actually no the translation (to avoid having any string translated twice).
The gettext/Qt guides I linked in the other thread might also be a good read.
I’m open to ideas on how to improve xl(), but existing implementations widely deployed in released code are the best guides I know and, for that, I think gettext/Qt are two good examples. In particular. we should also look at how phrases that differ based on single/dual/plural form are handled.
I think a limited set of keywords is probably not a good idea, although it would be nice if our %n$ or {n} form was named instead of numbered, I think; it gives the translator a better idea of what the whole sentence looks like.
Translated and translatable strings should never contain markup. If we need to use markup inside a translated sentence, the area containing the markup should be a placeholder.
Stephen,
Rather than re-hash above discussion again, please read my above messages.
“With a bit of documentation, translators should be able to handle them.”
Translators are unable to follow the simple rules in this page, much less parameterized constants(I say this from experience, since I am the one constantly fixing the google doc spreadsheet): http://www.openmedsoftware.org/wiki/OpenEMR_Internationalization_Development
To support parameterized constants would require more sophisticated backend tools to ensure the stability of the translations (possibly requiring moving from google docs to a custom translation platform). I’d suggest figuring out the current backend we use and then proposing/implementing tools to improve in that area; then can get on with the easy task of supporting it in the codebase.
As an aside, I think at this point, the limited developer resources is better spent on meaningful use and security hardening. We are likely not losing any userbase from not having parameterized translations; we support more languages than any other EMR and we support multilingual clinics, which I don’t think any other EMR supports. Not gaining meaningful use and demonstrating consistent work towards hardening security will cause a huge loss in the future userbase.