On Tue, Apr 30, 2002 at 08:44:32AM -0700, Paul Rohr wrote: > At 09:23 AM 4/30/02 +0200, Christian Biesinger wrote: > >Hm, I just realized that your approach does not help the case of identical > >english strings in different contexts. They'd get merged together (at > >least that's what the gettext tool does). > > Argh. That's the gettext "feature" that Andrew and others are complaining > about.
Well, that's the way gettext works, though.
> >If your tool would put the same
> >string more than once in the file, this would probably confuse translation
> >tools.
>
> Hmm. Given that translators are the folks who hate the feature, then I'd
> think they'd see this as a worthwhile bug to get fixed in their favorite
> tools.
Nevermind my comment here, since I suggested above to use the normal
gettest tool, which does merge the strings together.
> But then I'd also expected that they'd care enough to gravitate towards
> ID-centric tools, too. Shows that my intuition isn't always well-grounded,
> at least in this area. ;-)
Well, I personally prefer the gettext approach, both as translator and
programmer - as translator, I easily see what the english string is, and
need not guess from an ID, and as programmer, I just need to write
_("foo") to have a translatable string.
But true, it does have the disadvantage that the same string has always
the same translation...
> >> 3. transform the result
> >> ------------------------
> >> At *build time*, instead of running a gettext tool to create a .MO file,
> >> run one that creates a strings file with the appropriate IDs.
> >
> >That would require a tool which has a mapping of IDs to strings...
>
> That mapping shouldn't be too hard to get. The macroized header file where
> all the strings are found *already* maps IDs to strings -- indeed, that's
> what it's *for*. You "just" need to dereference appropriately.
Sure, but from a very quick glance I had the impression that the actual ID
is hidden by some macro (named dcl or something like that), so it might be
a bit of extra work.
But true, this is not really a problem.
> And yes, moving the charset conversion from runtime (where it's done now) to
> build time (as you suggest) might be helpful. It won't save us the
> footprint cost of including iconv in the binary, but it might decrease the
> working set on launch.
>
> >Or would that be incompatible with the strings file format? I've never
> >taken a look at them...
>
> Strings files are XML and include an encoding declaration.
OK, fine - I thought they were normal textfiles, something like
SOME_ID=The translation
Hm, I deleted too much of the quote, here's my comment on the convert
encoding on runtime vs. on compile time:
I mainly suggested that for performance reasons, not so much memory
reasons.
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-- Benjamin Franklin
msg24167/pgp00000.pgp
Description: PGP signature
