Am Mon, 2001-10-08 um 03.39 schrieb 1002505193:
> > You don't have to, that's the trick.
> Ok, I got the impression from your message that this was the case.
The trick about it is that there's nothing special, so you can use
any editor you like, like with ascii files just the XML represents
information structured.
> > Easy, you tell it.
> So this is an extra step that I have to do whenever editing a
> translation with your scheme?
Give it a default and change it whenever you do something differently.
> > Black magic but easy to hack.
> I'd like to see that hack first.
I'm no emacs crack but it should be quite easy to realise there. For
vim it's just a matter of minutes.
> No, I'm using Emacs pure and simple. And by the reasoning in your
> previous mail, you implied that it's an inferior tool, just because it
> doesn't natively support UTF-8 yet.
No, I assumed that emacs would support UTF-8 natively which seems was
sort of a naive conclusion by the fact that many people use it even
for webbrowsing and mailreading. It's certainly a very mighty editor
though I don't use it.
> Native support for UTF-8 is uncommon and of course that is bad and
> should get better, but that doesn't change the fact that forcing
> translators to use UTF-8 today causes real and practical problems for
> translators.
Consider tools that don't support UTF-8 buggy. And most certainly
those will be fixed sooner or later. As stated in one of my previous
mails emacs supports UTF-8 by installing an additional package so this
is not much of a problem.
> Editors aside, simply looking at and otherwise using console text tools
> on UTF-8 files with non-ASCII content, usually has little if any
> support.
Time for a reality check. Back at SuSE we had a special UTF-8 taskforce
and most of the developpers where quite surprised by the unveiled by
the results of their survey; quite a lot of the recent applications are
at least partly able to cope with UTF-8. There's no need to think
backwards when trying to plan for the future.
> We are not talking about some change that will give new functionality.
> We are talking about a proposed forced change that for all intents and
> purposes will give no benefit to translators (although you like to label
> them as such) but rather the opposite - instead of helping translators
> you want to make what they do more difficult, as has been already
> extensively discussed in this thread, with questionable gains at best.
No, I have no intend to make anything more difficult.
> > Heh, I you think work is lost then you're probably underestimating us,
> > of course someone will hack up a script to convert from the old to
> > the new style.
> That still won't solve the problems:
> 1) Your proposed solution still doesn't have the functionality
> of gettext as you described it,
It does.
> 2) Your proposed solution still doesn't solve the one-file
> problems,
It also does.
> 3) Your proposed solution still doesn't solve the problems of
> no other tools supporting this format, including translation
> memories and statistics tools,
Tools are very easy to write, just mention your wish.
> 4) Your proposed solution still remains vaporware for the time
> being.
No, it has been used in DIA.
> It's not the matter of a "simple script", and I sure hope that you do
> not still beleive so.
I do.
> You're certainly right about fear. Fear about a single person claiming
> that he can in no time replace software that has been evolved for
> decades, and that he intends to do so and enforce this change, all while
> this person openly admits that the proposed "solution" won't have hardly
> any of the essential features of the system to be replaced, and admits
> that he does hardly do any translation work at all, or understand why
> the features are necessary.
This is FUD, sorry.
> Sure, and we can do this already today by using the combination of XML
> and intltool.
It's okay, I got your point and we will go with the intltool solution
for now to please an apeace all the translators out there.
> I fail to see how Q_() will make software buggier (on the contrary I'd
> say), and I'm sure the persons responsible would like more constructive
> criticism and suggestions than "it's bullshit".
Gettext in general, though widely used, is bullshit; and a hack to cover
that fact won't make it better. Even if you add a hash like
"REW342rfwe!Some Text" to your strings to make it context aware you
haven't solved the problem but just worked around it in an evil way, not
to mention that this certainly doesn't ease the translators work you're
so eager to mention.
> Please explain (we can do that in private or preferrably on gnome-i18n
> since that surely will become off-topic), because although I'm highly
> sceptical to this as a solution for any forseeable future, I'm curious
> to what you have in mind.
Consider having a "master catalog", this one contains the basic
translations. Now you can have a "sub catalog" which is included in the
"master catalog" and can overide the translation in specified contexts;
this is part of something I would envision for the future.
> > Also having cluttered files definitely helps the
> > one-phrase-several-meanings problem
> Care to explain how?
See above.
> I must admit I had trouble parsing this sentence.
I said something like not reyling on .po files but a general machine
parseable format will allow a new dimeonsion of comfort with tools
you simply cannot realise at the moment. And there's no need to
show the people that they're really working on hundreds of files because
the view the application could provide simply hides that.
> Sure, but for all intents and purposes, this thread was about the GIMP
> tips.
I realised that though I'm researching a general solution for all
problems at once instead of reinventing the wheel for every single
feature.
--
Servus,
Daniel
