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


Subject: [xliff] (ISSUE 6) Revised Reformat and Translatable Properties withinXLIFF


This is from Mat  - his revised proposal for issue 6 

Reformat and Translatable Properties within XLIFF

 In theory there are three types of information stored within an XLIFF file

1)      Informational Values, such as file name

2)      Constraint values, such as MaxWidth

3)      Translatable values, such as Text and Font 

The problems

1)      Informational values, and constraints may not be modified during translation. If these values are only within the default XLIFF namespace, then the Specification can state what can and what cannot be modified.

2)      When using extended structures, we need a mechanism to indicate which extensions may be translated

3)      Translatable values may or may not be translated, depending on the type of file being translated. For example font may only be modified in specific file types. Mechanisms are required to control the translatability of each attribute or element, including extensions

4)      For each value that is modified during translation, placeholders are required to store the original and translated value for each attribute/element

5)      If XLIFF Files are delivered with source and target elements, the translatability of each attribute/element can be determined by its existence within the target. This causes further problems

a.      Each attribute/element within the trans_unit or source must also be applicable within the target.

b.      Some translatable values may be stored at higher levels of the hierarchy. They will also need place holders

c.      In a multi language translation environment, developers will submit a single XLIFF file with source only elements. Multiple files will be returned containing the required targets. Without the target element, the translatability of each value cannot be determined using this mechanism

Requirements

Simple, non-verbose, mechanisms to:

Ø      Indicate the translatability of any attribute/element, for XLIFF standard values or extensions.

Ø      Store source and translated values for any structure marked as translatable

 

Proposals

1)      A closed list of XLIFF standard attributes and elements that may be modified during translation. E.G state, target text

2)      Each member of the list will either have before/after placeholders or will be simply updated without keeping previous values

3)      No other attribute/element may be translated unless specifically marked as translatable

4)      Provide place holders for any modified element

 

Reusing the <default> mechanism

The ideas being suggested for <default> will specify a default value for any named attribute or element

The same mechanism can be extended to reformat, in that the named attribute/element may be marked as modifiable.

 Whatever solution decided for default should be equally applicable to reformat.

 The only problem is that a placeholder for each modified value will be required

 

Place Holders for modifications

The two variants of the <default> element are Global and Local

In the Local variant, each trans_unit has its own <default> structures

In Global, the defaults are specified at a higher level and standard scooping rules apply

Global

If the Global approach is taken, placeholders will need to be incorporated for any element/attribute

Any attribute/element used in trans_unit, source will also need to be specified in target

Any attribute/element used at group and file level will also need a placeholder, probably not within target

One option is to allow no modifiable attributes. All modifiable attributes are promoted to elements, and the target element is extended to also contain these translated elements

 

Local

If the local approach is used, the placeholder may be incorporated within the local reformat structure.

The reformat element may be defined at trans_unit, file, and group level

The reformat element has a single required attribute - the name of the single attribute or element that is being controlled

It has two sub elements, reformat_source and reformat_target, each of which has an optional ‘value’ attribute

If controlling an attribute, the ‘value’ attribute in each sub element is the source and target value of the attribute named in the parent reformat element.

 

If controlling an element, the source value is written into the reformat_source, and the translation of the element is written to the reformat_target

 

 

 

 

 



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


Powered by eList eXpress LLC