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: RE: [xliff] <bin-unit> problem

Hi Doug, John and all,

> * Should the <trans-unit> element for the 'alt' attribute be 
> WITHIN the <bin-unit> element or not?

I would say yes if you extract and process the GIF file, its place is in a
<bin-unit> and therefore the text associated would go with it, like you show
in your example.

In other case, where the image is not processed by the filter, I would use
two <trans-unit> elements: one for the ALT text, and one for the segment
where the image is. The image would be just a code. For example:

<p>Click <img src="start.gif" alt="Start!"/> to start.</p>

would give something like:

<trans-unit id="10" restype="alt">
<trans-unit id="11">
 <source>Click <ph id='1'>&lg;img src="start.gif" alt="@10"/></ph> to

And the filter would have its own mechanism to put back the ALT text at the
right place.

An alternative is to use the <sub> element with only one <trans-unit>:

<trans-unit id="11">
 <source>Click <ph id='1'>&lg;img src="start.gif"
alt="<sub>Start!</sub>"/></ph> to start.</source>

But I don't like it because it mixes two different segments in the same
<trans-unit>, and thus makes one change in either affects both (bad for

> * The URL in the src attribute can be changed, but does make 
> use of the <external-file> element. However, the 'restype' 
> attribute has "file" as a possible value, so I'm unsure which 
> to use.

I have to admit I haven't thought too much about filename changes. My
(convenient) answer would be that changing filenames is bad
internationalization and that one should have a language-relative folder for
images that can be changed (thus making the same in the file), but obviously
that's avoiding the real question. If I had to store a filename to be
changed in XLIFF I would probably use a <trans-unit> with restype set to

I completely agree that all those different things need to be put in clear
examples, same for resource-type files, etc.

I would even add some current problems in a different format:

In Windows RC files many resources have CHARACTERISTIC and VERSION
statements that I'm not sure how to store in an XLIFF document. Same goes
for load and memory options. Also the MENUEX resources has some properties
that don't seem to have corresponding attributes. And lastly, the FONT
statement in a DIALOGEX resource has 5 entries not 3 like our current 'font'
attribute allow. There is two additional values for italic and chraset
information. Should we do something about it?

> * Yves, what does 'kenavo' mean?

"Kenavo" is a Breton word equivalent (more or less) to "bye", "cheers".
Other variations equivalent to "see you soon/talk to you later" would be
"kenavo ar wech'al" or "ken ar c'hentan". Breton is one of the Celtic
languages, with Irish, Scottish, Welsh, Cornish, Manx and Galician. After
500+ years of forced-fed French culture (Brittany was attached to France in
1491, as part of the dowry of Anne de Bretagne when she married Charles VII)
not many people speak it fluently, but it remains alive.

I don't speak Breton, and know only a few words and expressions, but living
transplanted in deep frozen, arid, and land-locked Colorado I sometimes
yearn for the drizzle weeping from the low grey skies above the moor and the
woods, the scent of golden furze along the hedges of blackberry brambles,
the salty taste of the wind, and the cry of the seagulls, ...and I feel an
irrepressible urge to put a small trace of my native roots in my day :-)

<source xml:lang='br'>...kenavo!</source>,

<<attachment: winmail.dat>>

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

Powered by eList eXpress LLC