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

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

From: Robin Berjon <robin@berjon.com>
Date: Tue, 1 Jul 2008 15:36:20 +0200
Cc: www-svg@w3.org
Message-Id: <5AB6934F-F2FF-4D40-B73C-A74F7922887F@berjon.com>
To: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>

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.

> 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 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.

>> 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.  
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. 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. 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.

Robin Berjon - http://berjon.com/
Received on Tuesday, 1 July 2008 13:37:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:19 UTC