Hi On Sun, 18 Jul 2004, Denis Barbier wrote: [...] You're right, we should standarize some of these repeated phrases. Your proposal looks good. May I update those documents with this phrase? The fact is that some times we want to "translate" some non-human-readable things (like <book lang="en"> in docbook), and there are also many not-good DTDs out there, that put text into attributes. I think we shouldn't exclude them. Regards, Jordi Vilalta

On Mon, 19 Jul 2004, Michael Wiedmann wrote: Sorry, I meant only the attribute's value: "en". This is a necessary transformation for translated documents. I think that putting it as a string to translate is the easiest way to achieve it. Regards, Jordi Vilalta

On Mon, 19 Jul 2004, Denis Barbier wrote: I've been using poedit and it shows them well. But I agree with you on the translators behavior about the comments. With this you're forcing the name of the po file, not much interesting in some cases. And there's also another issue: there can be a language without the translated DocBook templates, and they may want to set the lang attribute to any arbitrary language. There's also the possibility to have more than one lang attribute (with different values) around the document. I think that another solution would be to create artificial msgids: "TRANSLATE ONLY AFTER THE ':'\n THIS IS THE VALUE OF THE aaa ATTRIBUTE OF THE ttt TAG: en" Maybe this isn't very friendly to pure translators, but I think that software translators should have a minimal idea about the format they're translating (see the 'E<lt>' stuff in the extracted strings from the man pages). Regards, Jordi Vilalta

On Tue, Jul 20, 2004 at 12:34:51AM +0200, Jordi Vilalta wrote: [...] There are 2 kinds of comments: those extracted from sources, and translator's comments. IIRC poedit was messing up those comments, there were discussions on Debian lists few months ago about this bug. I do not see your point here, sorry. Note also that AFAICT your solution below does not handle that case. They can be created by reading all *.po files. I tried this approach, and some translators did translate those msgids ;) I slightly disagree, my experience with po-debconf (a Debian specific tool) is that such tricks confuse some translators, so the question is: do we want a l10n framework usable by everybody, or by experienced users? IMO extra complexity should be added only when there is no other choice. I did not yet read the thread about the 'E<lt>' stuff, but these escapes appear in msgids, this is different from diverting msgids from their original role (ie. having msgid/msgstr handle original and translated strings). While we are talking about complexity, plural forms is a very hard topic, maybe it should be discussed too. Denis

On Tue, Jul 20, 2004 at 01:43:43PM +0200, Jordi Vilalta wrote: Ok, sorry for misinterpreting your statement, then. I agree that those tags do imply some extra burden on the translator shoulder. But I guess there is not much we can do. The solution may come from the editors. kbabel could well have an editing mode in WYSIWYG, undertanding and dealing properly with docbook tags. It should be doable, but I'm not sure it would be a good idea for now, since there is so much possible way to screw things up around. As said in the signature of the previous mail, I do belive that things must be made as easy as possible, but not easier. ;) It could be made an option, but the issue is that if the author makes its pot with one notation and the translator with another, you'll get fuzzies. Unless you implement also a on the fly convertion, but I'm not sure it worths the work. Thanks for your time, Mt. -- If the automobile had followed the same development cycle as the computer, a Rolls-Royce today would cost $100, get a million miles to the gallon, and explode once every few weeks, killing everyone inside.

On Tue, 20 Jul 2004, Martin Quinson wrote: [...] True. I think that the editors shouldn't interpret these things. It's a particular thing of po4a, and we should assume that the translators will have a minimal intelligence :P I think we should take an arbitrary decision and don't include this option, to avoid this issue about the fuzzies (and to reuse translations between projects, where each one could use a different option). Then, we should decide between one of these: 1) we use the same tag syntax for all the modules: this makes po4a more consistent (now that it's easy to mix more than one document format with po4a(1)), and maybe some translations could be reused between formats 2) each module can use its own format tagging: it makes modules easier to write In my personal opinion, I also like the docbook tagging more than the pod one. I'd like to follow the 1) option, although it's a lot of work for reworking the current man/pod modules. It's an unnecesary complication. Regards, Jordi Vilalta

On Tue, Jul 20, 2004 at 02:37:02PM -0700, Martin Quinson wrote: [...] You are right, I do not see tonight why I made this point yesterday, sorry. Denis

Quoting Jordi Vilalta <jvprat(a)wanadoo.es&gt;: I'd prefer to keep po4a format agnostic. The Right Format(tm) is very much like a religion question. It's impossible to make everybody happy. That's not an option here. Either we convert everything, or we convert nothing. That was the point of my previous mail, sorry for being so elusive. Since we cannot come up with a format which will make everybody happy, and not even with a format which may contain all the weirdness of all existing formats out there, I would prefer to keep those convertions to the very strict minimum. Read: I don't want to do any such conversion beside of the the Man format, where the native format is soo counter intuitive, user unfriendly and dying anyway. Pretty damn complex, indeed. texinfo share caracteristics with [La]TeX. There is a complete math formating stuff, complex table formating, cross-reference support, and even the possibility to program macro in order to extend it. XML does all this, but just with a completely different syntax/philosophy. That's not a surprise that no good converter for those system exist. It may be doable, but that's at least a 2 month work. I don't have that amount of time. I hack around po4a since a very long time, but it's usable by others only since recently. One of the showstopper was also the fact that it was debian only until you fixed the build mecanism. Yeah, exactly. As long as this is not addressed, those guys cannot use po4a. another issue seems to be that gettext expect the text to translate to be ASCII formated. It seems to choke on UTF encoded strings (such as when the text contain the name of a guy with strange chars in it). I'm hopping so ! But Sgml.pm will "normalize" the file, ie, put <section> alone on its line and so on... Of course you can write your whole document on one line, but you don't have to. And if you do so anyway, you won't be able to use po4a addendums. It looks like a fair deal to me. Likewise, groff allows you to switch directly from bold to emphasis without coming back to roman. Something like: \fBbold\fEemphasis, but not bold\fR roman again. And if you do so, po4a yiel at you. You should write: \fBbold\fR\fEemphasis, but not bold\fR roman again. ie, close the bold before opening the emphasis. I want to keep po4a modular, and make sure that adding a new format remains as easy as possible. I'm not speaking about adding a new xml dtd, W but a brand new format such as Debian and RPM package description, Debian changelogs (there is a big need for this one), debconf templates (in order to merge po-debconf and po4a), kernel 2.6 options (they changed it again), python documentation and so on. So the trend is to move more stuff from the modules to the core (file inclusion, for example. groff allows file inclusion, but Man.pm doesn't). What you propose whould go in the other direction. And after the po4aization of the Perl documentation, I'm ok with the addendums again. They do their job rather well, and I cannot think about an easier way to express what they have to express. If you have better ideas, of course, I'd be glad to hear about. Agreed. Thanks for expressing it. I'm glad to hear about it. Even if I don't agree with everything, the discussion is always good. Thanks for your time, Mt.