Hi Tony, I guess I may have jumped the gun slightly and perhaps should have verified and clarified my thoughts further before sending them. Your described approach will indeed work in the absence of text, though I still think it is somewhat inelegant. This is mainly due to the fact that the source information for translation is contained in the <trans-unit> as opposed to the <source>. Also I consider an empty <source> to be misleading and un-intuitive. However, its much to late for this discussion now, especially in the light of Doug's recent proposal to solve the 'reformat' requirement. Regards, Mark Levins IBM Software Group, Dublin Software Laboratory, Airways Industrial Estate, Cloghran, Dublin 17, Ireland. Phone: +353 1 704 6676 IBM Tie Line 166676 Tony Jewtushenko <
Tony.Jewtushenko@oracle.com> 24/01/2003 15:44 To Mark Levins/Ireland/IBM@LOTUSINT,
xliff@lists.oasis-open.org cc Subject Re: [xliff] reformat discussion Hi Mark and all: "XLIFF does not currently provide a mechanism for the localization of localizable data in the absence of text. It is also inelegant and unintuitive in its approach to modifiable data associated with text and lacks the ability to indicate the presence of modifiable or, more importantly, non-modifiable data". Unless I'm missing something, XLIFF already provides an adequate means for localizing localizable data in the absence of text. If a trans-unit is marked as "translate=no", and the source and target are left empty of text (ie, absent of text), then why can't the coord, style, css-style, etc., attributes be specified at the trans-unit (indicating source value) and, if different, the target (indicating localized value) level? Some of this issue was covered by the recent xliff comments mailing list discussion, but I thought the only issue remaining unresolved is identifying attributes that could or couldn't be changed in the target. There were some additional discussions about defining standard profiles to be used as templates for specific resource types, but that doesn't specifically preclude support for "localizable data in the absence of text". Can you please expand on your statement? We (at Oracle) make frequent use of text-absent trans-units, and once the reformat issue is resolved (per, say, Doug's suggestion) I don't grok any remaining limitations that would limit XLIFF from supporting any "localizable data in the absence of text". In fact, the solution is quite elegant and easy to read, in my opinion, and I'm not sure that significant architectural changes at any point in the future would improve it. Why doesn't </source translate="no"></target coord=x,y,x1,y1> work? Regards, Tony