F Wolff wrote: > On Di, 2006-09-05 at 13:52 +0300, Gintautas Miliauskas wrote: > >> Hello, >> >> nice to hear from you! >> >> >>> The only thing that concerned me >>> was the way plural forms are bundled in tuples, since the original >>> and translation seem to be abritrarily grouped with the English >>> singular going with the first plural form in the target language, and >>> the English plural form going with the rest. I guess this is the type >>> of thing you wanted feedback on ages ago but just thought it might be >>> worth raising again (obviously not expecting a change at this stage, >>> but maybe some time in the future...) >>> >> Changes can very well be done at this stage, even such significant >> ones as this, so if you feel strongly about this, let's discuss. >> >> The primary reason I chose tuples against a simple >> msgid+msgid_plural+msgstr[] is because that's what XLIFF uses. The >> XLIFF method is clearly more powerful and in general can not be >> expressed in PO. Other things can be dealt with in annotations, but >> this is quite a central thing, so I decided to go with the more >> powerful approach to avoid compatibility problems. >> >> > > Ok, I guess you say the xliff method is more powerful that po. But in > general, I agree with David that this is an unnatural grouping of the > terms, since the languages could have a different number of forms. With > xliff, the problem for me is that you need to know the number of plural > forms for the source language, because it can't be assumed from the > number of forms present in the file. It can only be assumed for the > target language. Furthermore, I don't know if the plural handling is > seen as such outside of the scope of the po2xliff representation guide. > > Of course, po is limited to en-US as source language, technically (in > this case, at least to singular/plural type languages). It is definitely > not as flexible as xliff, but I think what our base class allows is > universal, and will allow any source and target language. The number of > forms present in unit.source.strings is the correct number - if we let > the format take care of that. So I think it is more natural to group all > the source language strings together and all the target language strings > together. > > Our multistring implementation is also nice in the way that it allows > you to handle stuff as a normal string until you need to know about > plurals. > Exactly .... so I am not saying we should only support msgid and misg_plural like po format, I am saying it would make sense to have two separate lists, one of source plural forms, and one of target plural forms. In the PO format case the source list can only have exactly one or two strings, but in XLIFF it could be more general. It just doesn't make sense to pair the individual strings between source and target forms.
David ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Translate-pootle mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/translate-pootle
