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: RE: [xliff] XLIFF 2.0 Core

Hi David,

> It is my understanding that XLIFF can be used in these situations:
> 1. A format that product development can create to provide 
> translatable text to be translated.
> 2. A format that can be used within a tool set to manage the 
> translation of the content.
> 3. A format that one tool set can export which would then be 
> imported into another set of tools. 

I'm not sure #2 applies. If they keep their data within a unique toolset there is little advantage in using anything but some proprietary format it would seems. They only reason would if they want to be ready for #3.

> In my opinion, the Core could be different for each situation.
> ...

It's an interesting way to look at the core. But I think it quickly boils down to sets of functionalities more than users.

For example some users of case #1 may need to provide comments in the extracted documents, while other may not simply because their file format does not have  comments facility. Same for segmentation: Some original formats may favor pre-segmented entries (I know of one such case), while other (most) would simply generate unit-level content. So depending on various factors the same category of users may need different features.

I think the core can be defined in relation to the implementations: what is the minimal sub-set of XLIFF features a tool that reads XLIFF, makes modifications to it, and writes it back, should support. The more features we can get away with the better. But we have to remain realistic.

The minimal main type of operation a tool is likely to do on an XLIFF file is to change the translation.
That means it should probably be able to something like the following:

- make the distinction between different segments if the content of a unit is segmented
- read the source, and detect if it should/can be translated
- create the target element if it's not present, or detect the state of the existing translation
- understand inline codes in the content
- update possible status flag related to the translation
- preserve any construct it does not understand

Among those actions, already, some may or may not be considered core.

For example. Some tools simply do not deal with inline codes. Is that means inline codes should not be part of the core? Or is that mean 2.0 should not recognize such tool as compliant?
Personally I think marked-up formats are so prevalent today that even software-string oriented tools should be able to handle inline codes, but that is something we would need to specify in the conformance clauses. It may also be different depending on the type of tool: for instance I don't think we can force producer tools to generate inline codes, but we may want to force consumer ones to understand them.

Another example, is the translation status. Should a tool be obligated to update it? If the answer is yes, then such flag should be part of the core. If not, then it should be outside of the core.

My current thoughts are that if we can get away with a core that includes the features in the list above we would be already doing well. Today many tools don't even do that.

Then the additional features could be grouped in logical modules. If we manage to make them small and well defined, the tools could implement them step by step.

In some cases it won't be easy to define what should be the processing expectations for a module.
Notes/Comments for example. Is "supporting the notes/comments" module mean a tool should be able to do all or only some of the following actions:
- read notes associated to the unit/segment and present them to the user agent
- allow the user-agent to edit existing notes (or notes belonging to some categories)
- allow the user-agent to create new notes (or notes belonging to some categories)
- allow the user-agent to remove existing notes (or notes belonging to some categories)

My guess is that we will probably end up with mandatory and optional expectations.
But I'm getting away from the subject: defining the core.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]