On Sun, Aug 5, 2012 at 11:46 AM, Philippe Verdy
<verdy_p(a)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.