[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xliff] <bin-unit> problem
On the issue of file name changes: This issue is prevalent to
a high degree in Java with ISO 639/3166 tags appended to properties,
ListResourceBundles and typically to graphics, albeit through custom code.
It's unlikely that the Java community would move from that format. Any
argument over "same file names in language folders" vs. "same file names with
language tags" is "heated" and probably not worth labouring over.
I think I would prefer to see the "Tool" generate customised file name
transformations based on specific file format profiles (i.e., Java or GIF for
Java) rather than further muddying an already complex XLIFF document. For
example, a "Tool" could conceivably read the content of the <file> block,
assess the source language and then using the <target xml:lang="xx">
construct and build a map of the output file requirements. This would work
for graphics.
Just my 1 Euro's worth...
Cheers
Steve. Stephen Holmes
Voice: +353 (1) 241 5732
Novell, Inc., the leading provider of information solutions
http://www.novell.com >>> Yves Savourel <YSAVOUREL@TRANSLATE.COM>10/02/2003 18:11:52 >>> Hi Doug, John and all, > * Should the > WITHIN the I would say yes if you extract and process the GIF file, its place is in a in your example. In other case, where the image is not processed by the filter, I would use two where the image is. The image would be just a code. For example: Click would give something like: start. And the filter would have its own mechanism to put back the ALT text at the right place. An alternative is to use the element with only one alt="Start!"/> But I don't like it because it mixes two different segments in the same leveraging). > * The URL in the src attribute can be changed, but does make > use of the > 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 'file'. 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 :-) -yves |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC