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 ones excluded). > 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 good sides. > > 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 > future. 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 use myself. > 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 better. > 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 buggier. 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. -- Servus, Daniel
