Jordi Vilalta <jvprat(a)wanadoo.es&gt; wrote: I can't imagine that you want to translate a phrase like the above mentionend (book lang="en">), this should never be the case. Further in DocBook there should _not_ be any translatable text in attributes. Of course there could be DTDs with text in attributes so it would be good if this will be supported. Michael --

On Mon, Jul 19, 2004 at 11:22:56AM +0200, Jordi Vilalta wrote: [...] This would require a comment being added to PO files to let translators know how to deal with this msgid, and my experience is that translators hardly read such comments, because they use tools which do not display them (kbabel, gtranslator, poedit, etc, very few of them handle comments in a useful way). This attribute may be automagically added, e.g. including translations from xx.po could set lang="xx". Denis

On Tue, Jul 20, 2004 at 12:34:51AM +0200, Jordi Vilalta wrote: You mean that "<b>bla</b>" is more friendly than "B<bla>"? I don't see any difference... It's already better that the ".B bla" of groff (which must be alone on a line), isn't it? But if I had to redo the man module now, I'd go for docbook-like tag intead of pod notation. But I don't plan to change that for now... Bye, Mt. -- Everything should be made as simple as possible but not simpler. -- Albert Einstein

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.

I agree that 1) is the best, at the first glance. It wouldn't be that difficult to do in the Man module. There is already a conversion between the native representationS from/to the pod one. Changing it would be rather easy. Borrowing this into the pod module wouldn't be that hard either. And since po4a is getting used outthere, I'd say that we do have to implement this as an option, with the on-the-fly conversion. That's not very difficult either. But, you'll get ugly results if you have to mix between native formatting and common formatting. I mean, let's say we use the pod formating. How to deal with the (sg|x)ml "<a href=toto><b>bla</b></a>" I know that we would not take pod as common format, and that all marker of pod/man can be formated to ml ones, but it will change when another module for a more complete format gets finally implemented (texinfo comes to mind)... Moreover, my current concern with po4a are: - getting new blood here. New users, new contributor, new feedback. - put the file inclusion into the main modules - encoding - get ride of nsgml - texinfo module ... Bye, Mt. -- Freedom is not free.

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.

On Tue, Jul 20, 2004 at 10:17:07AM +0200, Denis Barbier wrote: In my mind, there is two approachs: - use the comments of po files for what they are made for. If editors do not display them, let's bug them. If translators do not read them and whine afterward, the answer is as easy as "RTFC" ;) - decide that comments get passed into the msgstr/msgid. That way, we can add stuff into those string which will not harm the document generation process. For format not allowing comments, tricks like the po-debconf "[:comment:]" could help, even if they are nasty. I prefere the first approach. I prefer to do it the Right Way(tm), and bug the ones who do not ;) Erm. I don't see your point at all. Those beast are very difficult while dealing with *messages* translation, but for now po4a only deal with documentation translation. In what situation could we have to deal with them? Maybe you mean that po4a itself should use ngettext in its messages? I should check again, but I'm not sure there is any string in po4a where it applies... Bye, Mt. -- Il y a 10 catégories de personnes : celles qui comprennent le binaire, et les autres. --- Blague d'informaticiens