2012/8/5 Harry Burt harryaburt@gmail.com:
On Sun, Aug 5, 2012 at 11:46 AM, Philippe Verdy verdy_p@wanadoo.fr wrote:
And then the multilingual version will be created by inserting the switch :
<text> <switch> <g systemLanguage="fr"> <tspan>...</tspan> <tspan>...</tspan> </g> <switch> <text> (the source language is normally kept as the default fallback language, the last in the switch). With this kind of layout, it will be possible for a translation to add or remove tspans as necessary, and to organize where line breaks will really appear, as their translation may not match one for one at the <tspan> level, but only at the <text> level.
At the moment, the extension generates
<switch> <text systemLanguage="xx"> <tspan>...</tspan> <tspan>...</tspan> </text> <text> <tspan>...</tspan> <tspan>...</tspan> </text> </switch>
Both your structure and mine are not easy to convert to variable tspan numbers within the context of the Translate extension, which assumes 1 to 1 parity.
Note also that the generated id's in the SVG for each successive fallback in the list of child elements of the <switch> each time adds a "fallback-" part before the new language code. This would create overlong id's like:
tspan3065-fallback-fallback-fallback-fallback-fallback-fallback-fr [snip] The "fallback-" part should only appear in the generated ID on the last child element of the switch. My opinion is that it is a bug of the ID generator.
It is, yes. Noted.
But even in this case, the "fallback-" part is never needed (look at the correct generated ID's for the parent <text> which just appends the distinct language code to the original IDs (note also that this simpler methods does not warranty that the generated ID will be really distinct, unless the original ID's before starting the translation to not create collision elsewhere.
The code checks for collisions. But yes, the fallback- part is totally unnecessary - another bug to squash.
Note also that the ":" character is allowed in an ID,
Uniqueness isn't really an issue at this point, because the code does check for collisions. Also, using colons could be confusing because of their use as namespace prefixes in SVGs.
The values of ID's are NOT in any namespaces. They are defined only in the scope of the document including them, which is the only virtual namespace. It is even safe to rename all ID's of a XML document (but this create problems when there are references to them as anchors from ****external**** documents, so if ID's are renamed, the document should have its URL location changed.
Namespaces are for naming element types and attributes.
Yes you can use dashes, but here again you'll need some prefixing rules to avoid collisions of IDs in the generated derived document. An ID generation scheme needs a limited fomr of stability anyway to allow SVGs to be translated in multiple steps without altering external applications referencing the SVG with for example an external CSS stylesheet using these IDs as selectors or anchors for the target URLs of xml:href="URL#anchor" attributes.