gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] EMR tree display of allergy


From: James Busser
Subject: Re: [Gnumed-devel] EMR tree display of allergy
Date: Sat, 20 Sep 2008 12:39:16 -0700

On 20-Sep-08, at 8:05 AM, Rogerio Luz wrote:

I prefer to have the Caveat field to ALWAYS show the allergic status (even if it is "null" or "not edited") this, IMHO is the necessary change in the Alergy issue I most want to see :) 

I agree. Maybe it is clearest to show in the Caveat the same allergy state "word" that is used in the buttons (translation)

Unknown (I suggest Unasked is better)
Undisclosed (I strongly prefer Unanswered)
None

Sorry about any downstream impacts (on translation) of GUI text changes although people may agree that it is premature to consider the GUI as suitable to be frozen... it has really not yet gone through a full cycle of discussion.

It makes a good point, though, on how to make changes adequately known to people.  While a scan of the Python source would achieve this, it may not be anything that anyone does routinely, and the maintainers (and users) of a language may like to avoid surprises when their first awareness would appear in a production client.

Maybe GUI text changes should be avoided in bug-fix-only releases. Maybe new-version releases could include drawing attention to GUI text changes (or maybe it should simply be assumed that these have occurred because new functionality can easily mean revision and/or revision to the GUI.

The information *might* also have be shared on gnumed-devel as part of discussion, however it may easily be missed and difficult to coalesce.

Should I maintain a wiki page which any person with interest could reference and use the built-in tool to display any diffs from when they last committed their .po file?

Would anyone want a notice of such changes posted to a new list gnumed-i18n ? It would be a low volume list and they would not even necessarily have to subscribe, they could just periodically lok at the archive.

Does the _po.sh script, after its merge with a $LANG.po file, make apparent not only strings that remain to be translated, but also translation stings that may be obsolete on account of the original (English) string no longer existing?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]