[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Profile: inline codes in software string
Hi Yves, Some good reasons for preferring the first option: 1) It gives better leverage across file formats. 2) It presents the text for translation in as "neutral" format as possible, thus making the job easier for both tools and people that need to process the file. Tools and people can process the content without knowing what underlying data format it represents. After all XLIFF should be about making interchange of data for localisation easier. Requiring tools and people that process XLIFF files to know about the underlying file format and the functionality of the filter that created the file should be avoided as far as possible. 3) If we leave the escaping and un-escaping responsibility to the filters we actually take away complexity from the localisation process, as there should then be one thing less to worry about... In cases were interoperation with an existing data source that requires "escaped" characters it is always possible to introduce the escaping for that particular interaction. However that should be the special case, not the other way around. It is my opinion that XLIFF as a standard should look at bringing the best for the future, rather than promoting "bad practices" simply because they have been used in the past. Regards, Magnus -----Original Message----- From: Yves Savourel [mailto:ysavourel@translate.com] Sent: Tuesday, April 20, 2004 11:09 AM To: 'XLIFF Main List' Subject: RE: [xliff] Profile: inline codes in software string Hi Magnus, > - Characters that would otherwise be interpreted differently > e.g. '%' in the case of RC etc., can be represented as plain > text without being mixed up with the placeholders. Thus the > translator does not need to be aware of the underlying file > format (e.g. to know that they must write %% when they mean %). I think that aspect is a different (but also important) issue. It applies even if the text has no variable, and to all type of resources, almost all type of text. The question is: How to hanle escaped characters? Should we "un-escape" the text in XLIFF and let the filter (knowing the format extracted) deal with the re-escaping? Or should we leave the escped characters as it and make sure translators (or any leveraging mechanism) does the proper escapes? Or, I guess, should we treat escaped character as inline codes? Ideally the first solution would be the best. But there are a lot of reasons the second can also be valid: - there are a lot of legacy TM with escaped data. - I don't think I know many main stream tool today that un-escape the text. - Some content can have many escape levels: (e.g. HTML in Javascript, in an XML repository, etc.) - Dealing with scaping/unescaping while going through a process that as as many step as localization may be more error-prone that just leaving the escaped characters. So I'm not sure which option would be the best choice. Note that all this is more for the 'resource' world, as in the 'document' world (HTML, XML etc.) characters are usually un-escaped by the filters. Cheers, -yves To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xliff/members/leave_workgroup.p hp.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]