← Prev in month ← Prev in thread
Next in thread → Next in month →

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

From
Sony Kewtushenko
Date
2002-12-09T21:19:23+00:00
ID
000801c29fc8$9ec150a0$
Thread
[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
← Prev in month ← Prev in thread
Next in thread → Next in month →