OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[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]