Am Sam, 2001-10-06 um 19.05 schrieb 1002387943:
> > That wasn't my point. I meant that it might be sensible for tips
> > (instead of introducing the header kludge) and for plugin descriptions
> > because it makes them more versatile and not bound to the distribution.
> I was referring to the tips and nothing but the tips.
Me not. I'm always a step ahead. Would you mind telling me why you want
to change the tips format, I must have missed that.
> I disagree. The english tips file has about 180 lines, with XML markup
> it will grow a little. At the moment there are 26 languages in ALL_LINGUAS.
> This would mean that the file would grow to over 5000 lines.
Do we have translations for all tips in 26 languages? XML don't grow
with the number of languages unlike the po-directory. And 5000 lines
are still a reasonable number considering that the German catalog for
app has more than 6000 lines.
> To edit your
> language, you'd most probably have to have two editor views open since you
> won't be able to get the original tip and your translation on the same
> page.
Please stop exagerating; a person that doesn't have a monitor that is
able to display 26 lines at once is pretty poor anyway.
> A second problem is encodings. There aren't many good UTF-8 capable
> editors out there and if you have all translations in one file, you can't
> easily convert to your native encoding for editing.
That's a good point. On the other hand we might want to go for UTF-8
though instead of having a whole bunch of different encodings, and then
there's still the possibility to escape special characters.
> As a translator, I'd
> prefer to have the original version in one file and edit a po file created
> from that source. If I am informed correctly, this is what most GNOME
> programs do or plan to do these days and there's a bunch of developer tools
> available for this purpose in the intltool module in GNOME CVS.
Hm, if you really insist on using the xml-i18n-tools that'd be fine
for me; it's just a small detail of the whole process.
> it is not very elegant, but I haven't yet heard one report where it didn't
> work or caused problems for externals. That said, I wouldn't object to a
> cleaner solution.
It works for now though it was quite some action when we implemented it
and it's still not sure it will work in the future; that's a very
fragile piece of code. However if you think about the plugin problem
that has been discussed every now and then heavily this is the only way
to solve it (well, at least no one mentioned a better one as of yet).
> I don't think we want to force plug-in developers into using glade.
Me neither, but something alike would be pretty cool. Since Mitch and
you already unified the plugins a quite a nice way this would be the
crown to it. :)
I'll address the rest of your mail in another email...
--
Servus,
Daniel
