Am Sam, 2001-10-06 um 14.33 schrieb 1002371616:
> > That wasn't my point. I meant that it might be sensible for tips
> > (instead of introducing the header kludge)
> What is 'the header kludge'? I never got that bit.
To use gettext on has to have a file with C syntax; the idea is
to have a header file where the original messages are defined and
then use gettext with that.
> Plug-ins are a whole different ball game by themselves. There still
> is no solution for distributing plug-ins apart from the few that will
> remain in the GIMP core distribution (the plug-in manager thing).
> Perhaps it is better to discuss plug-in localisation in that context.
IF we need to add another dependency it has to be worth it. Solving
problems by using XML for everything seems only clever to me. It does
not make sense to use XML for tip files while plug-ins still keep
in beeing broken (in the localisation context).
> Someone mentioned how well Dia seemed to be doing in that respect.
> Well, Dia puts the text strings for a sheet in a different file per
> sheet. Even with only 8 supported languages, this already looks
> totally cluttered to me.
Really? Everything is were it belongs to and nothing is used within
wrong context and, last but not least, its extensible and that even
easily.
> The tips file is 9 kB now. With 15 supported languages (how many on
> the way?), that would become 135 kB.
In contrary to po files untranslated messages are simply nonexistant.
And you forget one thing: All .po files together are by definition
bigger since the original text is repeated within every single file.
> We'd need a tool to merge changes, or would CVS be enough?
CVS seems fine to me, what would you need a tool for? There's no
need to merge catalogtemplates with existing catalogs in XML world.
> You cannot expect translators to wade through 30 lines of other
> languages to be able to add his/her own translation (30 lines per
> string to be translated, that is), so that translators do need to work
> on separate files.
Why not? And where do you get the 30 from? If you have 15 languages then
you'll have at maximum 15 times the original text to skip. Beeing a
translator myself (and in fact also one of the one of the DIA sheets)
I can tell that this is not as evil as it might look.
> It is just a subset of SGML you know, and not that
> good at it. There is nothing you can do with XML that you cannot do
> with SGML.
That's correct. Though there are much fewer tools for SGML than for XML;
why? Because SGML was and still is too bloated for many uses.
> XML apps are usually not meant to be read and edited by humans,
Huh?
> so I expect you have got a tool for the translators in mind?
If necessary I can hack something up but it should not be necessary.
I really don't see the big difference to hacking a .po file.
> gettext is also a standard.
Great. Show me the specs... I'm not talking about de-facto or so
called "industry-standards". gettext is such a crap that I really
doubt there was a standarisation process which led to a proper
specification.
> XML was developed to give marketdroids a
> new fad to woo, whereas gettext was developed to let translators do
> their thing.
XML was designed to have a standarised markup language to allow
human readable, verificable and interchangeable files. Don't follow
the hype but choose the best of all worlds and that's where XML
chimes in; sure you can use this approach here and the other there
but in the end you're just wasting your own time by thinking of new
formats and algorithms to parse them.
> I know which I as a translator prefer.
Allright then, I'll keep it in mind.
> If we tarred the tips directory, would that solve your 'many files'
> problem? ;-)
I don't care about the amount of files in special directories or
the final tarball, I care about the number of libraries in /usr/lib
and hundreds of files /usr/share/locale/*/LC_MESSAGES though....
--
Servus,
Daniel
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
