Am Son, 2001-10-07 um 18.43 schrieb 1002473012:
> Then you should take a new look. It certainly does today.
Fine with me.
> Why should I have to use a special XML editor?
You don't have to, that's the trick.
> How does the editor know what language I want to edit,
Easy, you tell it.
> and how does it automatically filter away
> everything else except the original string and my language?
Black magic but easy to hack.
> Do you believe everyone uses VIM or has the desire to be forced to do so?
No, but having the right tools will always have a big impact on the
efficiency of your work. I really don't want to know that you're using
to edit textfiles but if you're not skilled with one of the major
ones (No, MicroSoft Notepad and Wordpad are not major) then you're most
likely wasting your time.
> Surely all translators are bound to agree with you. All incompatible
> 8bit encodings are a nightmare, and UTF-8 is the future. But that
> doesn't change the fact that we live with the tools we have today. We
> cannot stop translating or reduce the pace of translations until we live
> in a UTF-8 clean world, because simply there may never be such a world,
> and it is out of our control as translators, and for most idividual
> developers too, I'd imagine. It will be a long conversion process, and
> we have to support multiple encodings during that time. We can already
> store translations in UTF-8 today, but editing them is another matter.
This is free and open software, no one is used to walk the hard way just
because there are only a few tools available; pick one of the available
tools or improve others instead of living in pain.
> Also, the encoding problem remains to be only one of the problems with
> your solution.
Now we're getting closer to the point I hope.
> So you're saying that Emacs and many other editors are bad? Please don't
> turn this into an editor war.
Emacs can't do UTF-8?
(minutes later) Hm, okay I imagined a major editor like emacs would
support UTF-8 natively but I was proven wrong. Though there is a
package here ftp://ftp.cs.ust.hk/pub/ipe/oc-unicode-0.72.2.tar.gz
that adds the missing support to version 20.4 (20.6 preferred).
Actually I really don't care what people are using and I'm not saying
any editor is worse or better than any other (well, the most obvious
> Escaping isn't realistic at all. I suspect your experience with having
> to write large amounts of text in your native language and escaping all
> non-ASCII characters is limited.
I have to do that all the time, Umlauts in LaTeX are preferrable escaped
by an ", and in HTML or DocBook I also have to use the escaped versions,
so what's the matter?
> It plain sucks for more ways than is possible to count.
Welcome to reality, sucks eh?
> Escaping everything reduces typing speed (and makes
> your fingers hurt),
Well, some editors can do it for you but then there're people who
prefer american keyboard layout and thus have no choice.
> makes it hard to read, introduces a greater danger
> of errors (by forgetting to escape, or incomplete escaping) or wrong
> escaping (one different escape sequence is similar to all others, while
> the result may be entirely different. In other words, a pain to verify
> without unescaping).
Again, this is something you shouldn't have to care about; the
ridicoluous speed increases of computerearchitectures also have their
> > See above. Try the folding feature of vim 6.0, it's really cool.
> I don't use vi or vim, and do not plan doing so for the forseeable
I believe this is one of the features vim has copied from emacs, so if
you're a fan of this brew you should be happy as well.
> That's the problem. You are only prepared to replace some limited
> gettext functionality, ignoring the rest.
Okay, I'm waiting for the promised next mail. :)
> They are not. How much do you translate a day? Much of what you base
Almost nothing at the moment because most of the interesting software is
already translated and I'm far too busy to care about features I don't
> because of the tools. Translation memories and fuzzy matching are most
> important parts of this.
Fuzzy matches often lead to wrong translations unfortunately. And one of
the major problems with the catalogs of big applications is that one
cannot easily translate a phrase differently in differing contexts.
> I hardly would consider any change of this pace to the worse, because
> some developer decided that his homebrewn (but for all practical
> purposes inferior) and incompatible translation scheme should be used,
> for any progress. And this is what I'm afraid of.
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. Just the handling in the future would differ and as I
already said it's more the fear of a change then a real deterioriation
that would be seen here. Moving to a better machine readable format
also has the advantage that the machine can support the user much
> Yes, it's a fear. Fear of having an inferior translation scheme enforced
> by someone not completely understanding the problems and difficulties of
> daily translation work by translators, and willing only to replace some
> limited functionality while ignoring much else desperately needed
> functionality. I'm not saying that this is necessarily the case here,
> but it sure reminds me of every such previous discussion I've had.
Okay, I will silently accept your POV here since it doesn't make any
sense to elaborate this any further to me.
> I agree that this is a drawback of gettext (solvable by using the Q_()
> macro in intltool instead of _() or N_()),
Ugh, _() and N_() were invented to reduce the overhead to a minimum and
still many developpers haven't understood the idea behind it. Q_() is
really about the biggest bullshit I've seen for quite a while and it
surely will not make the concepts easier to understand and the software
While I do agree with Marc that XML is not the all-purpose solution I
really think it's going to help in the case of localisation by the
consistent use of UTF-8 and other concepts like includeable files and
overrideable tags. Also having cluttered files definitely helps the
one-phrase-several-meanings problem though I see that it's hard to
understand that several files don't automatically mean a deterioriation
in comfort given that the tools to support the people would be easier to
write than a reply to such a mail and they would have functions no
one would probably expect from a .po editor with it's fuzzy messages
and translation pool.
> but do you really expect the
> same tip to occur more than once in the tips XML file, and require
> different translations at the same time?
No, I was talking about translations in general here.
Gimp-developer mailing list