On Mër , 2004-05-19 at 21:25 +0800, Not Zed wrote: > On Wed, 2004-05-19 at 08:10 -0400, Rodney Dawes wrote: > > The recent changes to use "e-error-tool" for the error XML files, has > > broken "make dist", when "make" has not been previously run, as the > > e-error-tool is written in C, and is not built durint the dist stage. > > > > Why exactly are we using this? If intltool is stripping whitespace, > > why hasn't a bug been filed? The intltool scripts will need to get > > fixed regardless of whether we want to use them or not, and we are > > already using them for a lot of other things in evolution, so I > > don't see why we shouldn't use them here. > See previous emails. > > I even asked about using run-time built tools and you said 'sure, that > will work'. If make dist can't work with C built tools, then make > dist is braindead and broken. intltool does some bullshit crap perl > regex xml parser which just plain doesn't work. Well. It seems to work for .schemas, .server, and all kinds of other files that are just xml. I don't recall ever saying that using run-time built tools would work for make dist. I just reverted my widgets/misc/ directory to before you committed the e-error-tool changes, and added some extraneous whitespace/text that intltool handles fine. If you just add extraneous trailing or beginning whitespace, it does get chomp()d. Though, you shouldn't have any extraneous trailing or beginning whitespace like that. > > /* Quote from previous mail I did not have time to read/reply to due > > to the insane amount of work I had to do at the time */ > > > > > I haven't filed one, nor bothered to look - i'm lazy. I'd like to > > > move away from it if possible, for this case it just makes things a > > > _lot_ more difficult and less efficient for the code than it needs to > > > be, and bypasses much of what gettext() gives you in the first place > > > from a coders pov. > > > > How does intltool bypass what gettext() gives you as a coder? The only > > thing intltool does is to make using the command-line gettext tools for > > actually managing the translations in cvs/etc... easier. You can still > > use the exact same gettext APIs if you so please. None of the _()/etc... > > wrapper macros are in intltool, those are all defined in glib, IIRC. > > In fact, as stated in some of the bugs in bugzilla, we have to use the > > ngettext() call instead of _() in several places, for the plural > > translations. > Well, with intl tool you have to do all your own language checking and > then pick out the right language for the right locale based on what > you look up yourself abou tthe environment. I.e. it throws away all > of the basically language-independent hash-table lookup which gettext > provides, and gives you ... absolutely nothing at all. It totally > throws away all of the memory and performance advantages of using > gettext and makes you do ALL language lookup manually. So yes, it > totally bypasses what gettext gives you as a coder - YOU CAN'T CALL > GETTEXT IF YOU'RE USING INTLTOOL ON XML FILES. I know _() is only a > macro to call gettext - like DUH. This is just false. If the translations are in the .po files, then they end up in the .mo files that get built and installed. What you can do is just get the untranslated string and pass it to gettext, which should give you the translated string. It certainly does for me. I was not saying that you didn't know what _() was. There is obviously confusion about what intltool does, and what you can do with it, so I was trying to clarify the location of the API. There is no need to get angry. > ngettext is completely irrelevent to this case, particularly since > intltool doesn't do any of that for xml files, either. It is less relevant, I'll grant you. But I would leave it at that, and say that this is a bug in intltool that needs to get filed, and fixed somewhat soon. We really should have a way to specify in xml, that the string can be plural, so that intltool does the right thing for the translators in that regards. -- dobey
Attachment:
signature.asc
Description: This is a digitally signed message part