category-brainstorming: Difference between revisions
(added a lot of feedback/commentary - mostly from IRC last night) |
(→issues: rm cr) |
||
Line 85: | Line 85: | ||
== issues == | == issues == | ||
<div class="issues"> | <div class="issues discussion"> | ||
* I think the main implied use case here would be better researched, analyzed, and developed through the creation of: | * I think the main implied use case here would be better researched, analyzed, and developed through the creation of: [[localization-examples]], [[localization-formats]], [[localization-brainstorming]]. — [[User:Tantek|Tantek]] 23:41, 1 September 2009 (UTC) | ||
</div> | </div> | ||
Latest revision as of 23:48, 1 September 2009
category
is a field used in many microformats, originally taken from hCard.
Type name: CATEGORIES Type purpose: To specify application category information about the vCard.
— RFC2426
It is closely related to rel-tag, but has no dependency on URL schemes, it simply marks up the inner-text as a category keyword.
Brainstorming on this page may be applicable to parsing of category
and/or rel-tag.
Supported Languages
An object — a person, or item (in a hProduct or hListing context) — may be consumable in multiple languages. A person may communicate in multiple languages, a set of self-assembly shelves may come with an instruction manual in multiple languages, a web application (also a product) can be localized to support use in multiple languages.
In a loose form, supported language is a form of categorization, but it is useful to filter by language separately from other tags/categories (‘Only show me people that speak languages I speak’, ‘Only show applications available in my language’).
Localization vs. internationalization need to be distinguished. The term "language" is too abstract/vague/ambiguous in this context.
examples of language publishing
Language on the web are indicated in multiple forms on the web:
Note: at least a live URL example for each of these would help make these examples appear less theoretical. — Tantek 23:41, 1 September 2009 (UTC)
- Names (e.g. ‘Français’, ‘Deutsch’, ‘English (British)’
- Abbreviated local names ‘En’, ‘Fr’, ‘De’
- Abbreviated country names: ‘GB’, ‘UK’, ‘ES’
- Local names (e.g. ‘French’, ‘German’, ‘British English’, ‘Dutch’)
- ISO 639 language codes (e.g. 'en-gb', 'en', 'fr', 'de')
existing formats for marking up language
HTML already has a lang
attribute for marking up actual content. This uses ISO 639 codes.
brainstorm requirements
Categorizing languages has the following requirements:
- Differentiate from other types of category
- Why? Based on what use case(s) and what real world examples? — Tantek 23:41, 1 September 2009 (UTC)
- Allow the language to be presented in local name form
- Needs citing of real world examples that do so. — Tantek 23:41, 1 September 2009 (UTC)
- Allow the language itself to be ascertained reliably and interoperably
- Based on what use case for ascertaining? — Tantek 23:41, 1 September 2009 (UTC)
Proposal 1: class='category language'
- Use an additional class-name
language
to indicate that a category is marking up a supported language for the object.- See above re: localization vs. internationalization. This choice of term is too ambiguous and does not relate directly to a particular use case. — Tantek 23:41, 1 September 2009 (UTC)
class=language
also instructs parsers to read the ISO code from thelang
attribute of the element, in place of the inner text, where present.- Parsers are *already* reading the lang attribute of the element. — Tantek 23:41, 1 September 2009 (UTC)
- If you want a generic mechanism for pulling a microformat property value from the "lang" attribute of the element rather than the contents of the element, then it might be better to follow the pattern set by the value-class-pattern's "value-title" and introduce a term like "value-lang". — Tantek 23:41, 1 September 2009 (UTC)
e.g.
<ul>
<li class="category language" lang="en-gb">English (British)</li>
<li class="category language" lang="en">English (American)</li>
<li class="category language" lang="fr">Français</li>
<li class="category language" lang="de">Deutsch</li>
</ul>
In HTML, the strings should be marked up with a lang attribute to ensure that the local named languages are pronounced correctly by screen readers (for example).
With rel-tag:
<ul>
<li><a class='language' rel='tag' href='/apps/lang/en' lang='en'>English</a></li>
<li><a class='language' rel='tag' href='/apps/lang/en-gb' lang='en-gb'>English (British)</a></li>
<li><a class='language' rel='tag' href='/apps/lang/fr' lang='fr'>Français</a></li>
<li><a class='language' rel='tag' href='/apps/lang/de' lang='de'>Deutsch</a></li>
</ul>
In this case, the URL scheme is shown to also use ISO codes. This may not be the case in production environments (they may choose to use /apps/lang/english
, for example), so parsers look explicitly for language information should be instructed to again look for for the lang
attribute where rel-tag is used in combination with class-language.
--BenWard 01:16, 1 September 2009 (UTC)
Questions
- JonathanMalek 15:19, 1 September 2009 (UTC): I've been looking for ways to express more information about a particular category. For instance, when categorizing a particular hAtom entry as "about Los Angeles, CA", it would be helpful to also mark up that particular rel-tag with the geo data for LA. Do you see this
category
proposal as a way to support richer tags?
issues
- I think the main implied use case here would be better researched, analyzed, and developed through the creation of: localization-examples, localization-formats, localization-brainstorming. — Tantek 23:41, 1 September 2009 (UTC)