On Thu, Mar 30, 2000 at 08:49:16PM +0200, Stanislav Brabec <utx@xxxxxxxxxxxxxxxxx> wrote:
> -- Other problem is about translating some splitted messages to many
> languages (gender problems etc.) Example with Czech:
> Free = Volny (Selection)
> Free = Volna (Curve)
Yeha, that's a long-known gettext limitation. In Apache::PApp, I will soon
support language-tagging and id-tagging. Sinc eit's perl, I'll just append
a zero byte and the neecessary information, but I am really looking for a
gettext replacement (maybe just a dbm-file(?)).
The short-term solution with gettext is indeed adding prefixes (nonsense ones
like "#1 Free" or "Free ~curve", "Free ~selection" and then use a en_US
translation table to map these to english.
This would be similar to the xopen way, but for long messages (which are
very probably unique), you could "just" use the message as key, and for short
messages (like "Free"), you would just add a suffix or some other tag, since
the chance of collisions is very high.
That could be done before 1.2, with added stress for the translators, but...
> -- Jpeg: There is a problem to guess compression and some save options
> from jpeg data. So we load image compressed in 98% quality,
> and consequent Save will default to 75% quality.
I don't think this really is so much of a problem. Saving a jpeg in the same
quality as it was originally saved will do no good to your quality. The only
thinvg it will ensure is that the file-size will be similar.
> Tell it the programmers; they will have to add "prifixes" to make the
> strings different; e.g.:
I think using optional(!) tags (which will be more verbose) will be even more
useful: Not much added strain on the programmer, not much strain on
translators (we need one more translator for the en mapping).
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
