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 GmManualBasicEmrConcept.

The VCS tree contains concise notes on how to go about a translation.

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:

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 and

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

Work in progress…

Members of a translation team can upload files, as can (apparently) drivers. Relevant help pages:

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."

Having pushed a set of existing translations into Launchpad, we did not so far figure out whether or how to further use Launchpad's direct browser-based upload/ import tool – policies here. If we would use it, there has been confusion on how to properly use this… that is maybe best explained with bug 264109 which came after bug reports 60939, 229026 and 264101.

Miscellaneous notes taken from Launchpad Translation bug reports

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 <>\n" are some sort of gettext system builtin default. The FR is taken from the intent, the 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. 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. 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 which generates a new po file and uploads it to launchpad.

Previous to a release I go 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.
Topic revision: 16 Apr 2015, KarstenHilbert
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark