Translating the GNUmed User Interface

GNUmed has been translated into a few languages, but if the translation for your language doesn't exist or is out of date, you can help bring GNUmed to entire new populations simply by translating some text. See how thoroughly (if at all) GNUmed's currently ~ 1900 expressions have been translated into your language.

Before doing any translation, it will be important to get a clear understanding of some terms as used by GNUmed, for this please first see BasicEmrConcept.

A free Launchpad account will allow the above translations to be improved online. (A multilingual medical office assistant with bits of time would be invaluable for the health oriented expressions, which make up ~ 2/3 of the overall, and leaving the more-technical terms to others.)

Shortcuts to untranslated strings are as follows:

• Spanish
  • https://translations.launchpad.net/gnumed/trunk/+pots/gnumed/es/+translate?show=untranslated&start=46
• German
  • https://translations.launchpad.net/gnumed/trunk/+pots/gnumed/de/+translate?show=untranslated&start=46
• French
  • https://translations.launchpad.net/gnumed/trunk/+pots/gnumed/fr/+translate?show=untranslated&start=46

If you can't work online, but actually join the Launchpad GNUmed development team, you can download the .po files either from Launchpad or in a development copy of GNUmed – notes here. Third-party tools to consider include translate.google.com and dictionary.reverso.net.

The CVS tree also contains concise notes on how to go about such translations.

If you followed the above advice and created a translation for your language feel free to send the .po file to the list for inclusion into the next release. Thus your effort will not be lost while GNUmed keeps developing.

Work in progress…

We did not yet determine when and how (having pushed translations into Launchpad) to further use Launchpad's direct browser-based upload/ import tool – policies here. There has been confusion on how to properly use this (best explained with bug 264109 after bug reports 60939, 229026 and 264101. Maybe good to know that in bug 264121 a Launchpad worker states "We have bzr imports now. We should point out that option here as the preferred means of upload."

Only members of a translation team, not drivers or release managers, could upload files. Please remember to read the relevant help pages. https://help.launchpad.net/Translations/YourProject https://help.launchpad.net/Translations/ImportPolicy

Translation strings that are "too long", per gettext format definitionem result in a
msgstr ""
line, ignored upon compilation into a .mo file. Seems these are not displayed in Launchpad as needing fixing.

Gettext file lines like "Language-Team: FR <LL@li.org>\n" are some sort of gettext system builtin default. The FR is taken from the intent, the LL@liremoveme.org probably has got some historical meaning.

If there is anything but the language code and the ".po" in the file's name, the import system won't recognize the language and the file is held for manual review.

... "I ran "msgfmt -c" again and i got no errors. The file is currently in the "import queue", i have a few days waiting for approval. What could be wrong? -> Chances are there's a problem with a Windows-style line ending: a carriage-return character and a line-feed character. Sometimes we see the closing quote appearing between the two, in which case some programs will see the carriage-return as a newline and others will not. Thus msgfmt will not complain, but Launchpad will.

---

https://bugs.launchpad.net/launchpad-foundations/+bug/229026 As at Set 1 2009, all templates get "imported" as if the branch owner did it. Or something. We should definitely try to email just the person who has requested the import, or set it up. Once fixed, on any future updates, it should be the committer.

---

https://bugs.launchpad.net/rosetta/+bug/264101 Denis Arnaud reports a problem with the Breton (br) translation for the Hardy firefox-3.0 package. He first uploaded a PO file (after fixing the many errors you typically get for an attempt to do that) and then later an XPI file. He uploaded the latter into the Breton translation, not into the template.

The XPI upload failed: the importer mistakenly believed that it was a PO file! The reason for this seems to be that the POFileUploadView prefers the existing POFile's path over the uploaded one. It does not pass a format to TranslationImportQueue .addOrUpdateEntry(), so addOrUpdateEntry() guesses the new file's format based on filename. In this case, that's the old PO filename instead of the new XPI filename.

A simple way to work around this is to make the POFileUploadView prefer the new upload's name if it has an extension that differs from what the existing POFile in the database has. A more sophisticated one would be to reuse the name in the database, but replace either the extension or the entire filename (leaving the rest of the path intact).

---

One day I decide that I've added enough a sizable amount of new strings to the client. I run push-po-file-to-launchpad.sh which generates a new po file and uploads it to launchpad.

Previous to a release I go get-translations-from-launchpad.sh which downloads what exists there, merges with what is in CVS and commits.

So it'd be great if we could get the apparent po jam cleared up and a document telling me how to upload .pot/.po from the command line.