W3C home > Mailing lists > Public > www-svg@w3.org > July 2008

Re: How to provide titles and descriptions in a second language?

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Tue, 1 Jul 2008 17:25:24 +0200
To: Robin Berjon <robin@berjon.com>, www-svg@w3.org
Message-Id: <200807011725.24206.Dr.O.Hoffmann@gmx.de>

Robin Berjon:
> Hi Olaf,
> On Jul 1, 2008, at 10:19 , Dr. Olaf Hoffmann wrote:
> > Robin Berjon:
> >> Nothing keeps you from providing title and desc in more than one
> >> language: simply use the xml:lang attribute to indicate which
> >> language
> >> they're in.
> >
> > xml:lang provides a different information - it just indicates in which
> > language the content is, this is no indication of an alternative or
> > for whom this information is relevant, obviously authors may
> > use it independently from other purposes to avoid plurivalence
> > and confusion within the content. In the world today there are
> > many loanwords/'xenocism', sometimes even with different
> > meanings as in the original language (for example anglicisms
> > and pseudo-anglicisms).
> >
> > http://www.w3.org/TR/SVG11/struct.html#LangSpaceAttrs
> Yes, as a French speaker I am well aware of loanwords  I do not
> however for a single second believe that they should be marked as
> coming from a foreign language using xml:lang. The purpose of xml:lang
> is IMHO /not/ to provide linguistic markup (if so, it is way too weak)
> but rather precisely for this sort of purpose.
> Of course the XML specification itself is completely fuzzy on the
> issue, and expresses no semantics whatsoever. The SVG specification
> should make its use of xml:lang more explicit.
> The 'switch' element is part of the processing chain, which to me
> indicates that you only want to use it for things that have
> conformance criteria in the specification. You don't want to use it
> for metadata as metadata is static and should not be dependent upon a
> specific processing context.

Well if we assume that someone wants to generate an alternative
text representation using mainly titles, descriptions and text elements,
it can be pretty helpful to follow those switches to something which
explains the purpose of the document in a similar structure than
the primary graphical content.

The problem with plurivalent words and loanwords with another
meaning is more probable for the short titles, included in a
longer text. In the description or a paragraph it is typically
no problem to have a good guess, what something like
'tags' means. But in titles this word is a problem:
In 'pure' german it means something completely different
(tags = 'in the day'), but including 'denglish' / anglicisms this can 
be a technical term in german too for 'HTML or XML tags' - 
structure indicators in markup languages or alternatively
some specific graffiti on buildings similar to a signature . If an
author of an elsewhere almost german document sets the
xml:lang of a title element to  'en' this might be already an 
improvement indicating the usage of 'denglish' / anglicisms ;o)
Similar problems I already had with short 'denglish' 
titles of some movies - it takes some time to guess, what
the intended meaning really is without any further information.
Of course, authors using xml:lang typically will maybe tend to
avoid 'denglish' anyway and do not have the problem.
But such a 'denglish' mixture is obviously intended for some 
specific german audience, not in general for english,
therefore the xml:lang might be a help for the audience to
understand 'denglish' but is no option to chose something
for english audience and not providing it to audience understanding
'denglish' more or less.

Therefore xml:lang should not be overloaded with another function
as to indicate the language of the content for whatever purpose.
This is typically not required for any 'xenocism' in a paragraph, but
helpful under some circumstances and for shorter text fragments
like titles.

> > And I think, it would be a much better user agent, if any title and
> > desc is somehow accessible in an alternative presentation of the
> > document. Typically especially document title and desc provide
> > important information about the content of the document, at least
> > in almost any of my SVG documents ;o)
> Agreed, I'm just saying that it shouldn't be up to SVG to decide which
> language to show. 

If this is the intention of the author - why not?

> If there are several titles in several languages,  
> the UA should make them all available, and use the one (possibly by
> default) that the user prefers.

Do you think, there will ever be a popup window before such an SVG
document in advanced browsers, that the user has to decide first,
which language to show? 
Else it is already the functionality of systemLanguage. 
The user already noted in the preferences of the viewer, which language
is preferred and the viewer can use systemLanguage to choose without
doing anything with xml:lang only indicating the language of the content,
not to whom this content is intended.

> >> just include several, each with their own
> >> language. It's up to the UA what happens with them (e.g. showing up
> >> as
> >> a tooltip or being read out) so it ought to figure out which one it
> >> wants to use.
> >
> > 'It is strongly recommended that at most one 'desc' and at most one
> > 'title'
> > element appear as a child of any particular element'
> >
> > http://www.w3.org/TR/SVG11/struct.html#DescriptionAndTitleElements
> >
> > A who we are to do it differently as 'strongly recommended'? ;o)
> We are smart people who thing that SVG kicks arse but isn't perfect.

Obviously not ;o) systemLanguage functionality can be improved too.
Currently it has the problem, that the author cannot know what the
user prefers and what is still readable for him.
For example, is it better to write

<text xml:lang="de" systemLanguage="de">tags drauf</text>
<text xml:lang="en">the next day</text>

<text xml:lang="en" systemLanguage="en">the next day</text>
<text xml:lang="de">tags drauf</text>

Many germans are able to read both 'de' and 'en' but will prefer 'de'. 
Native english speakers beeing able to understand german will prefer 
typically 'en'. 
What to do is currently statistics, the author cannot satisfy them all.
Typically the probability is bigger to have a reader of the first type,
or to have readers not beeing able to understand german but 
understand at least some kind of english, therefore my guess is that 
the first sample is better but still has some currently unavoidable 

And note that this has another meaning 
(and could be even an illegal incitement):

<text xml:lang="de" systemLanguage="de"><tspan xml:lang="en">tags</tspan> 
<text xml:lang="en">tags upon</text>


If you have 'title' instead of 'text' you are in trouble anyway here as the
author. But there is a way out already - one can use another 
markup language inside title, desc and metadata according to the
specification, therefore one can use xhtml:span instead of svg:tspan in
the title element to provide the xml:lang to a plurivalent expression. 

> IMHO that's a leftover from SVG 1.1 and was designed mostly for UA
> implementers too lazy to figure out what to do in the situation in
> which several titles or descs were present. 

Yes, indeed this can be improved.

> I'd recommend replacing it 
> with something along the lines of "Several 'title' or 'desc' elements
> may be present, for instance representing titles and descriptions for
> the same object in several different languages, as marked by the
> 'xml:lang' attribute.

better systemLanguage attribute, see above, don't mix functionalities ...
if possible do not use one screw for too different purposes at the same

> User agents that expose the 'title' and 'desc' 
> elements may wish to provide only a subset thereof (e.g. only those in
> a language recognised by the user).".
> The above is not mandatory and therefore somewhat fuzzy, but then
> again very little about title and desc are. I think it has the
> advantage of clarifying the recommended behaviour in a way that is
> sensible given the input.
> The alternative is to add Conditional.at to the title and desc
> elements in the schema, but I'm not convinced that that is a good idea.
Received on Tuesday, 1 July 2008 15:27:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:14 UTC