On Sat, Apr 01, 2000 at 07:46:03PM +0200, Marc Lehmann wrote:
> That could be done before 1.2, with added stress for the translators, but...
> 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).
On Mon Apr 3 15:06:25 2000 Daniel Egger wrote:
>> Tell it the programmers; they will have to add "prifixes" to make the
>> strings different; e.g.:
> That's not meant to be serious, is it? It would be really a
> pain-in-the-ass to maintain this, even in the most simple case.
I am thinking about less stressing version:
Little change in gettext (or some post-code), creating two catalogs:
gimp.pot and gimpR.pot.
gimp.pot will not be affected by any post/prefix.
gimpR.pot will contain only post/prefixed messages in full version.
So, gimp.pot will be translated in standard way, gimpR.pot will stay
untranslated unless one actually need difference between strings.
Both can be merged during compilation.
This affects:
-- gettexting mechanism in code (we need two lookups - with and without
post/prefix).
-- needs extra code in addition to standard "gettextize".
-- definition of __ in header (or optionally redefinition of _ - see lower)
Don't affects:
-- Already existing translation.
For example:
code.c:
__("selection~Free")
gimp.pot
#: code.c:111
msgid "Free"
gimpR.pot
#: code.c:111
msgid "selection~Free"
There are two ways to create pre/postfixes: "preventive" (do it for
all possible problematic strings) and "on demand" (if any translation
in any language looks ugly, one (the translator) will do it).
I see also one chance: Automatic prefix generation on c-filename basis.
It's sufficient for most cases (but not all), and requires only re-defining
of _ macro. __ macro (and prefix) will be used explicitly only for places, where
per-filename prefix is not sufficient.
For example:
code.c:
_("Free")
gimp.pot
#: code.c:111
msgid "Free"
gimpR.pot
#: code.c:111
msgid "code.c~Free"
>
> > -- 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.
>
Saving in higher quality means vaste of disk space. Saving with less quality
will cause loss of quality. So the best is to save certain jpeg in the same
quality all times.
--
Stanislav Brabec
