2012/8/5 Harry Burt <harryaburt(a)gmail.com>:
> 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.