2012-10-15 21:23, Andreas Prilop wrote:
http://translate.google.com never translates <code>...</code> .
It is therefore not necessary to write <code translate=no>
or <code class=notranslate> . I think this is a good idea.
On practical grounds, it might be seen as a good idea. Computer code is
generally meant to be language-invariant, and it is better to avoid
translating source program code, markup, commands, or other <code> content.
Still, on logical grounds, computer code as such is not
non-translatable. I'm thinking of comments mainly, of course.
Could <code translate=no> be made the default in HTML5
for the code element?
I have no strong opinion on this. Pragmatically, it might be a good
idea, though perhaps Google and friends will keep doing whatever they
are doing, anyway. Logically, it would be odd. The "translate" attribute
as such is questionable. An attribute name that is an English verb
suggests that it is a command, or at least suggestion. But attributes
are supposed to be declarative.
Appropriate markup would say that the content of the element is to be
treated as not being in any human language, for the purposes of
translation, spelling checks, text concordance analysis, etc., but may
still be treated as being in one or more human languages in speech
synthesis. If such markup were available, <code> elements could have it
set by default, provided that there is a way to switch it off for
comments (and maybe for string literals).
But there's a completely different meaning for translate=no, as
exemplified by the following code at
http://www.w3.org/TR/html5/global-attributes.html#the-translate-attribute:
<p>The Bee Game is a text adventure game in English.</p>
<p>When the game launches, the first thing you should do is type
<kbd*translate=no*>eat honey</kbd>. The game will respond with:</p>
<pre><samp*translate=no*>Yum yum! That was some good honey!</samp></pre>
Perhaps a better example would be the statement "The plural of 'ox' in English is
'oxen'",
where it would of course be absurd to translate "ox" and "oxen". This is very
different
from the <code> case: here the language of the content is certainly a human
language,
well identified and mentioned in the context. The content could surely be
translated; it
just should normally not be translated. Though this might really seem to call
for command-like
markup, the logical structure is that the words "ox" and "oxen" should be taken
as
linguistic objects rather than normal words. They could well be translated in a
rendering
mode where a document is displayed in its original language but translations to
another
language are displayed e.g. on mouseover, as explanations. The same applies to
the example
above: normally not translated, but surely translatable, much more than
computer language
keywords and variable names are.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
