[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Some initial ideas for XLIFF 2.0
Hi all, First of all, congratulations to you all for your work on XLIFF 1.2! In last months' tele-conference I mentioned that I'd throw some futher ideas for XLIFF 2.0 up on the list. However I haven't had time to properly articulate them yet... I'll put some initial thoughts down in this mail as a start, although we might leave the discussion until next meeting as this mail came rather late. [Improved whitespace handling] - See separate mail [Better support for XML localisation] - The W3C International Tag Set (ITS) standard defines i18n properties for XML based files. Could we use this to better handle XML files within XLIFF? [change-tracking / version control] - preliminary support through the <phase> element and phase-name attribute. - Doesn't support all features, e.g. what if I want to know in which process the 'merged-trans' attribute was set for a <group> [Fine-grained validation & permission control] It would be useful to have a language to be able to specify e.g. that in the 'review' process, a reviewer can only change the 'state' attribute and add notes, and in the 'tm matching' process, a tool can only add <alt-trans> elements. After a process is completed, we could then automatically validate the XLIFF files that the constraints have been met according to the specification. [Document-centric vs Resource-centric translation] XLIFF 1.2 is in many ways a resource-centric approach to translation, and doesn't take into account some of the needs in document-centric translation, such as e.g. reordering of paragraphs, 1-n, n-1 and n-n translations. Is there a need or a case for developing a document-centric and a resource-centric extension, with a common core schema? [Resource Inheritance] - For some l10n libraries, it is common to support language inheritance, in that if a resource is not specified in the specific locale (e.g. en-AU), then look at the more generic locale (e.g. en). Handling localisation of these resources in XLIFF is quite ad-hoc with XLIFF 1.x. I.e. there is no 'right' way for an editor to specify 'use the more generic locale for this resource'. [XLIFF Templates] - provide a special target-language-neutral XLIFF template 'blue print' that is used to initialize each language-specific XLIFF file. cheers, asgeir
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]