G
A
Adrienne Boswell
Gazing into my crystal ball I observed Ganesh <[email protected]>
writing in @p10g2000prm.googlegroups.com:
No, you have to do some reading yourself. They have an alternate way of
looking at the data, but it seems pretty easy to understand.
writing in @p10g2000prm.googlegroups.com:
No, you have to do some reading yourself. They have an alternate way of
looking at the data, but it seems pretty easy to understand.
G
Ganesh
I tried validating with wcag20 validators, surprisingly some found
seashell.co.in valid while some found it invalid.
some found use of lang="en-us" invalid while some do not report it.
When I reached the page of w3c ISO 639 it is reporting it as
"Obsolete".
When I checked this page http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
I do not see any reference for en-us
but, I have found lot of important resources using this convention.
src:
http://www.w3.org/WAI/ER/IG/ert/iso639.htm
G
Ganesh
correction w3c ISO 639 http://www.w3.org/WAI/ER/IG/ert/iso639.htm page
as "Obsolete"
and i did not find reference of en-US anywhere in any of the ISO docs
related to Language codes
G
Ganesh
I find "en" is the code to be used
http://www.loc.gov/standards/iso639-2/php/code_list.php
I found a reference for en-US at http://www.ietf.org/rfc/rfc4646.txt
so, is it fine to use en-US?
H
Harlan Messinger
Ganesh said:
Of course not. ISO 639 covers language codes, like "en". The code "US"
is a national code, covered by ISO 3166. The two are used in combination
to specify the variety of a language being used--but, of course, this
does no good in a context where only the code for a language is expected.
A
Andy Dingley
WCAG 1.0 was rubbish
WCAG 2.0 is still rubbish
Read the "WCAG Samurai" site for what's wrong with them, or Joe
Clark's Accessibility book for what you ought to be doing instead.
G
Ganesh
Yes, I've changed the lang="en-US" to lang="en"
now website seashell.co.in validates with http://achecker.ca/checker/index.php
for WCAG 2.0 AAA
G
Ganesh
I am sorry i had used
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en-US">
for this the http://achecker.ca/checker/index.php reported invalid.
when I used <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-
US" lang="en-US">
http://achecker.ca/checker/index.php reported valid.
so, this tool had spotted the difference in the conventions used my
me.
G
Ganesh
G
Ganesh
Well, it's there's wrong it could be up corrected with WCAG 3.0. As, I
said before only GOD's perfect. We are humans, we have to keep
correcting things version by version. I am sure there will be problems
with WCAG Samurai too, if it is not made by GOD
A
Andy Dingley
ISO 639 defines codes for languages, e.g. "en"
ISO 3166 defines codes for countries, e.g. "us"
IETF (the people behind the internet RFCs) language tags are used in
web work. These are a sequence of tags and subtags (up to 9, AFAIR)
but the most common use is with the tuple of ISO639 - ISO3166 together
eg. "en-US", or else the bare ISO639, e.g. "en"
G
Ganesh
So, is this valid en-IN?
G
Ganesh
I am wondering what would this "hi-US", or "gr-US", "ar-GM" be?
shouldn't that be a huge complex list?
G
Ganesh
A
Andy Dingley
Yes! Probably quite a significant one.
A huge _potential_ list. You only have to express the entries that are
actually important.
In practice, anything serving content should have a fallback behaviour
that is to match on the language+country if it can, or to match on the
language alone if that's the best it can offer. Also remember that
browsers can request a sorted list of preferences, not just one "all
or nothing" entry.
So a site for tourism in New York could author content in the local en-
US, translate it to French & German and maybe even offer en-GB with
"colour" instead of "color" etc. Browsers preferring the following
requests might be served as follows:
Denver, US wants en-US receives en-US
London, UK wants en-GB receives en-GB
Vancouver, Canada wants en-CA receives en-US (best available)
Delhi, India wants en-IN receives en-US (en-GB would probably
be closer, but the site isn't smart enough to know this)
Paris, France wants fr receives fr-FR
Quebec, Canada wants fr-CA receives fr-FR (best available)
Roma, Italy wants it but receives en-US (there's nothing to
offer for Italian)
Strictly the IETF system supports notions of "sub language" tags, so
that specific requests can be made as "Hinglish language" rather than
"English as spoken in India". That's more precise and also copes with
countries that have different sub languages of the same basic language
(UK has English sub-variants as Received Pronunciation Queen's
English, Cockney, Geordie, Scouse, Ulster Scots and many more). I've
never seen this used though beyond a technology demo or a political
statement, language + country is as far as anyone goes.
A huge _potential_ list. You only have to express the entries that are
actually important.
In practice, anything serving content should have a fallback behaviour
that is to match on the language+country if it can, or to match on the
language alone if that's the best it can offer. Also remember that
browsers can request a sorted list of preferences, not just one "all
or nothing" entry.
So a site for tourism in New York could author content in the local en-
US, translate it to French & German and maybe even offer en-GB with
"colour" instead of "color" etc. Browsers preferring the following
requests might be served as follows:
Denver, US wants en-US receives en-US
London, UK wants en-GB receives en-GB
Vancouver, Canada wants en-CA receives en-US (best available)
Delhi, India wants en-IN receives en-US (en-GB would probably
be closer, but the site isn't smart enough to know this)
Paris, France wants fr receives fr-FR
Quebec, Canada wants fr-CA receives fr-FR (best available)
Roma, Italy wants it but receives en-US (there's nothing to
offer for Italian)
Strictly the IETF system supports notions of "sub language" tags, so
that specific requests can be made as "Hinglish language" rather than
"English as spoken in India". That's more precise and also copes with
countries that have different sub languages of the same basic language
(UK has English sub-variants as Received Pronunciation Queen's
English, Cockney, Geordie, Scouse, Ulster Scots and many more). I've
never seen this used though beyond a technology demo or a political
statement, language + country is as far as anyone goes.
G
Ganesh
I think I would better keep that as "en" from accessibility point of
view. That would keep it simple.
I have seen an Arab speaking English, if you have ever heard it, its
very unique and does sound very attractive as well.
J
Jukka K. Korpela
Andy said:
Well, both of them are a mixture of rubbish and useful points, flavored with
some nondescript substances. The problem is that very few people can
distinguish the bad parts from the good stuff.
That might be a good idea for many of us, but I don't think it's
particularly effective if the real goal is to make money (fast, preferably)
by selling accessibility-related services without understanding
accessibility.
G
Ganesh
they use RFC1766 for language code
<!ENTITY % LanguageCode "NAME"
-- a language code, as per [RFC1766]
-->
please referrer http://www.w3.org/TR/html4/strict.dtd (open this file
in a notepad)
J
Jan C. Faerber
x-no-archive
http://www.w3.org/TR/2004/WD-WCAG20-SCRIPT-TECHS-20041119/
This might be interesting for you in that context.
Where by ecma is not a w3c standard.
http://www.w3.org/TR/2004/WD-WCAG20-SCRIPT-TECHS-20041119/
This might be interesting for you in that context.
Where by ecma is not a w3c standard.