XLIFF Inline Markup SC

Hi all, To get the discussion going on the topic of addition/deletion of inline codes. Here are a few thoughts: === Indicators: - we need a way to indicate if a code can be duplicated - we need a way to indicate if a code can be deleted - do we need a flag indicating if a code can be moved out of order? === Additional codes: - we need a way to represent a new code (i.e. created after the initial extraction) - we need a way to represent a duplicated code (i.e. created from a cloneable existing code). A first option for the indicators: -- An attribute (e.g. 'perm') with a numeric value that is the ORed result of individual values. - can be duplicated = 0x1 - can be deleted = 0x2 - can be duplicated and deleted = (0x1 0x2) = 0x3 For example: <code id='1' perm="3"/> -- Another option would be to use a set of letters indicating the permissions: - can be duplicated (cloned) = "c" - can be deleted = "d" - can be duplicated and deleted = "cd" or "dc" It is slightly easier to implement. For example: <code id='1' perm="cd"/> Or use a list of values: perm="delete;clone" In all cases, the default would be that an inline element can be cloned and deleted. Like in 1.2. The attribute would be available for all elements that represent code for native data, regardless of the notation. Note that in 1.2 the clone attribute can go only on <g> and <x>, not <bpt>, etc. Any thoughts? === Representation of added codes: --- new code created after extraction. Those are codes provided by a tool during, for example, edit. For instance to bold a word not bolded in the source language, etc. They are no correspondence in original document and not in the skeleton. - what id should they have? (assuming is a required attribute) - should providing the native data mandatory? Or can just providing the type (e.g. bold) and let the tool add the code if it can is also something we want to provide? --- Duplicated code. They should point to the same native data as the code it has been duplicated from. - what id should they have? (assuming is a required attribute) - should they just have the same id as the original code? And we assume the tool merge the same native code. -ys

Hi Yves, all,

Thanks for getting the discussion going. Please find some comments/thoughts below.

Cheers,
Christian


Original Message-----
From: Yves Savourel [ mailto:ysavourel@translate.com ]
Sent: Montag, 11. April 2011 16:54
To: xliff-inline@lists.oasis-open.org
Subject: [xliff-inline] Inline codes properties

Hi all,

To get the discussion going on the topic of addition/deletion of inline codes. Here are a few thoughts:

=== Indicators:

- we need a way to indicate if a code can be duplicated

CL> Would we just talk about "duplication", or rather about "multiplication"?

- we need a way to indicate if a code can be deleted

CL> I wonder if we need a "note" or "constraint" mechanism here (as well as for "multiplication", and the other scenarios)
CL> in order to capture information under which circumstances the modification is allowed or even mandated.

- do we need a flag indicating if a code can be moved out of order?

CL> I wonder if we need to discuss the impact of this in case of nested codes. Do I have to move inner codes if I move outer codes?

CL> Asides:
CL> 1. Would the indicators be set information architects (when they create a schema)?
CL> 2. Could the indicators only be set "inline" (as suggested by you on the code, or - similar to itsRules - also elsewhere)?

=== Additional codes:

- we need a way to represent a new code (i.e. created after the initial extraction)

- we need a way to represent a duplicated code (i.e. created from a cloneable existing code).

CL> Might we need a representation for a derived (or modified) code as well? Example: When going between languages or during copy editing an "i" might have to be turned into an "em".

A first option for the indicators:

-- An attribute (e.g. 'perm') with a numeric value that is the ORed result of individual values.

- can be duplicated = 0x1
- can be deleted = 0x2
- can be duplicated and deleted = (0x1 0x2) = 0x3

For example: <code id='1' perm="3"/>


-- Another option would be to use a set of letters indicating the permissions:

- can be duplicated (cloned) = "c"
- can be deleted = "d"
- can be duplicated and deleted = "cd" or "dc"

It is slightly easier to implement. For example: <code id='1' perm="cd"/>

Or use a list of values: perm="delete;clone"

CL> I think pros&cons for the individual options depend on the question who will have to set the values.

In all cases, the default would be that an inline element can be cloned and deleted. Like in 1.2.

CL> I guess I would need some background, why that's the preferred default.

The attribute would be available for all elements that represent code for native data, regardless of the notation. Note that in 1.2 the clone attribute can go only on <g> and <x>, not <bpt>, etc.

CL> Not sure (see remark above on "constraints") - my gut feeling is that some native data never must be duplicated (think for example of some Javascript that is hidden in a "style" attribute).

Any thoughts?


=== Representation of added codes:

--- new code created after extraction.

CL> See remark above on "derivation": We may have to distinguish between genuinely new, and derived. In both cases, we may need to capture additional information. Examples: "Created by edit tool to allow for Y" or "Derived from X (replaces X) by edit tool to allow for Z".

Those are codes provided by a tool during, for example, edit. For instance to bold a word not bolded in the source language, etc.
They are no correspondence in original document and not in the skeleton.

- what id should they have? (assuming is a required attribute)

CL> I would tend to generate new ideas. In addition, in the case of derivation (or multiplication), I would use something like "rel" to capture a relationship (for example "I have been derived from X".

- should providing the native data mandatory? Or can just providing the type (e.g. bold) and let the tool add the code if it can is also something we want to provide?

CL> Not sure that I understand the question/example.

--- Duplicated code.

They should point to the same native data as the code it has been duplicated from.

- what id should they have? (assuming is a required attribute)

- should they just have the same id as the original code? And we assume the tool merge the same native code.

CL> See remarks on added code above.

-ys



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

>> - should providing the native data mandatory? Or can just >> providing the type (e.g. bold) and let the tool add the >> code if it can is also something we want to provide? > > CL> Not sure that I understand the question/example. Should we allow <g ctype='bold'> as a new code? A code which does not have an actual native data associated with (because it's new), but just the information about what it represents. Or should new codes always provide the native data? -> <bpt ctype='bold'>&lt;b></bpt> -ys

Hi Yves,

Thanks for the explanation.

I am tempted to say

New codes should always provide native data

Rationale

If only a substitute is used (e.g. 'bold' in <g ctype='bold'>),
additional processing (e.g. derivation of native format such
as HTML with CSS) may not work too well.

Cheers,
Christian


Original Message-----
From: Yves Savourel [ mailto:ysavourel@translate.com ]
Sent: Dienstag, 12. April 2011 15:54
To: xliff-inline@lists.oasis-open.org
Subject: RE: [xliff-inline] Inline codes properties

>> - should providing the native data mandatory? Or can just
>> providing the type (e.g. bold) and let the tool add the
>> code if it can is also something we want to provide?
>
> CL> Not sure that I understand the question/example.

Should we allow <g ctype='bold'> as a new code? A code which does not have an actual native data associated with (because it's new), but just the information about what it represents.

Or should new codes always provide the native data? -> <bpt ctype='bold'>&lt;b></bpt>

-ys


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi Yves and Christian,

I must admit my temptation goes the other way. I'd rather not overload the XLIFF with non-XLIFF, non-translation data. My bias is that the transformation tool should bear the burden of managing the format, not the localization interchange file.

Thanks,

Bryan


Original Message-----
From: Lieske, Christian [ mailto:christian.lieske@sap.com ]
Sent: Thursday, April 28, 2011 4:16 AM
To: Yves Savourel; xliff-inline@lists.oasis-open.org
Subject: RE: [xliff-inline] Inline codes properties

Hi Yves,

Thanks for the explanation.

I am tempted to say

New codes should always provide native data

Rationale

If only a substitute is used (e.g. 'bold' in <g ctype='bold'>),
additional processing (e.g. derivation of native format such
as HTML with CSS) may not work too well.

Cheers,
Christian


Original Message-----
From: Yves Savourel [ mailto:ysavourel@translate.com ]
Sent: Dienstag, 12. April 2011 15:54
To: xliff-inline@lists.oasis-open.org
Subject: RE: [xliff-inline] Inline codes properties

>> - should providing the native data mandatory? Or can just
>> providing the type (e.g. bold) and let the tool add the
>> code if it can is also something we want to provide?
>
> CL> Not sure that I understand the question/example.

Should we allow <g ctype='bold'> as a new code? A code which does not have an actual native data associated with (because it's new), but just the information about what it represents.

Or should new codes always provide the native data? -> <bpt ctype='bold'>&lt;b></bpt>

-ys


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php