Minutes: GEO telecon 040804

 
MINUTES: I18N GEO TF telcon, 2004-08-04 at 16:00 UTC/GMT, 9am Seattle, 12noon Boston, 17:00 London, 18:00 Paris, 2am Melbourne
Attendees: Richard Ishida (Chair I18N GEO), Deborah Cawkwell (BBC World Service), Andrew Cunningham (State Library of Victoria), Susan K Miller (Boeing), Tex Texin (XenCraft) 

Scribe: Deborah Cawkwell

Info Share
DC: Unicode training (UniClinic) to be held at BBC for World Service developers amongst others. Training to be provided by a group TT belongs to. RI would like to attend; to speak to TT.
RI: Web Services I18N task force has just produced a document (http://www.w3.org/TR/2004/NOTE-ws-i18n-scenarios-20040730/)http://www.w3.org/TR/2004/NOTE-ws-i18n-scenarios-20040730/)
First announcement of I18N FAQs from W3C home page. Text was: "2004-07-30: The GEO Task Force of the W3C Internationalization Working Group publishes information to help authors and Webmasters understand and use W3C technologies. Articles in July: FAQ: Why should I use the language attribute in Web pages?, FAQ: Should I declare the language of my XHTML document using a language attribute, the Content-Language HTTP header, or a meta element?, FAQ: How do I use .htaccess directives on an Apache server to serve files with a specific encoding?" This was agreed with Communications Team; it offers great visibility.  

Meetings
Review of holidays over summer period.
NO MEETINGS FOR REST OF AUGUST
RI away 14 - 28 August
DC away same two weeks
Susan has taken holiday
No meeting during time RI away, note to be sent out.
Russ will be out on 18th
RI checked time of meeting was OK: yes for DC & SM. 

Review of GEO Work Items:
http://www.w3.org/International/2003/plan.html
RI changed the format of the 'plan' document to make it more usable: initial part (Discuss at next meeting, etc) will change from week to week; some stuff is repeated. 
TT joined the meeting.
Tests - RI & DC to discuss. RI: would like to publish/take to Note an I18N GEO document in September. For this to happen all the tests to be in place. Ideas about other tests to run are welcomed. Andrew is working on test for the position of meta charset wrt title element. Lloyd is not around at the moment (& has been unwell). MD's test on form & encoding possibly won't happen. RI will contact Francois Yergeau & John Yunker.
Leslie Fountain is doing a usability review on GEO website, which should be interesting. LF works with a usability company in London. DC asked if this review would involve scenarios. RI is not expecting huge report, but some useful pointers.
Re linking between translated versions in a page, the group discussed & RI has implemented on the GEO site. RI to write up what was learned.
Rechartering process continues with request sent to AC reps re patent policy. We will move to new policy beg Sept, then go into re-chartering.

Discussion
See http://www.w3.org/International/2003/plan.html#meeting
Summary of process for developing material.
Proposed process summary with a more formal process. It follows discussions between RI & Addison Phillips on how the different groups in I18N will work together once GEO becomes a Working Group. RI feels it is useful to have it written down: not *absolute* rules, but the basic shape. One main difference: additional review for wider mailing (wider I18N & also Core); it will provide useful feedback. This review would take place *after* discussion within group. TT suggested a minimum set of requirements, that wouldn't curtail output when people get the urge & just write something, then feedback later. RI agreed that it was not desirable to inhibit excitment, but it's useful to announce intent in case other people are working on the same thing. A formalised documented process would be especially useful for new members of the group. But there is a need to strike a balance.
AC joined the meeting.

Authoring Techniques for XHTML & HTML Internationalization: Specifying the language of content 1.0 (http://www.w3.org/International/geo/html-tech/tech-lang.html)
What do we need to do to get it to Note status? The group should email with any suggestions/improvements. 
Discussion re UA testing: we should show whether UAs support a particular feature, choose a base version & track changes since that base version & add information on any changes. But it seems quite a challenge in terms of resources: would require a test *group*, where this work is currently individual. UA support is still very important. But there is a question of published documents gradually becoming out of date. Another possible approach would be to run tests on base UA versions & add the latest version available at the time the document is published. This would make life simpler & an additional facet would be it shows way forward more clearly with a clear signal to upgrade browsers. DC added that BBC browser support standards also reflected this approach. GEO does not have the resources to offer a complete suite of tests; there are too many differences, eg link element, only works with Mozilla & v 1.6, differences between Mozilla 1.6 & Firefox. RI had been wondering whether Firefox should be included, though revisions are coming fast.  Documents should present sets of features for developers to understand & offer information about what can be done today. Manufacturers also do their own marketing of what their latest UA versions support. TT added that even when a new UA is released, the user base does not necessarily upgrade to that latest version. But RI said the approach of including tests on the latest version points to the way forward & there is also a mechanism built into the documents where we can talk about specific versions. DC: it would seem there are two remits: telling people what they should be doing for I18N now & evangelizing, eg use language attribute & applications will be developed to use that feature. It was agreed that tracking all new releases would be too difficult & resource-intensive. Additionally, anyone with an interest in a particular version, can take a test & run it for themselves. We shouldn't couple tests & the documents together too strongly; the documents shouldn't necessarily have to catch up. GEO also has an overview document, where we can publish most up-to-date results. We must be careful too: tests need moderation & checking. TT suggested involving the mailing list. RI suggested that documents would provide test information about the baseline & latest UAs & just those two. TT asked how is that different from the original? RI said the original was baseline with a commitment to track every change; for the future we need to simplify. TT agreed that it is not practical to track every change & that we probably didn't need to be so strict to begin with. TT asked what is the real cost, one person for a week, group for a day, etc, & raised the issue of cost vs value of tests. Also the test burden effects publication output productivity. 

Web documents with more than one primary language
Authoring Techniques for XHTML & HTML Internationalization: Specifying the language of content 1.0 Section 3 Declaring the primary language of a page
http://www.w3.org/International/geo/html-tech/tech-lang.html#ri20030510.102829377
AC said that in his view of multi-lingual pages, the primary language is defined by the language of the navigation & the meta data. RI said he *previously* agreed. A question to ask is *why* do we need to know what is the primary language. RI: *multiple* audiences may be targeted by a page, not just the audience of any primary language. TT added that providing content in a language should also address localisation issues, such as units of measure, etc, eg the French-speaking audience of France would have different localisation issues to the French-speaking audience of Canada.. Additionally, there are documents that address multiple audiences/markets that might not (need to) change language, but should address localisation issues, eg, the three audiences of US, South Africa, UK, where English is common. This localisation issue is an inherent part of what people *really* need, but not reflected in our description. RI asked how we apply this to our document? DC suggested acknowledging that issue, but stating that it was out of the current scope. TT to write something up.
Tex left meeting
RI: the real question is what useful nuggets do we need to pass on? RI's current thinking was that multi-lingual documents are those that repeat the same information for two sets of users, where the navigation, etc, could be in one language or another. AC said that the navigation may be seen to define the *primary* lang, but this does not entail that the document is not multi-lingual. It is not uncommon to see English pages with other languages embedded, Australian government pages can work like this. A worse example is where all content is in another language, but all the meta data & navigation is in English. There is a need to distinguish between sites that localize navigation & sites that don't. RI: we do make a distinction between (1) specifying the language used for processing content, and (2) using meta-data to identify the audience for the document. How you define what is the primary language may vary. The question is how do you practically do it. If there are two languages, then advise to use  the http header & meta element, if equal then divide as best as possible. SM hadn't been able to find examples of pages of multi-lingual pages, where there wasn't a clear primary language. RI hasn't either, but believes there are some EU examples. Some multi-lingual pages can function as 'staging posts'. AC had noticed some multi-lingual page in three languages, but they were no longer live. In Australian government circles, it's quite common to have two languages. AC to send example URLs. RI to look too. There should be a description of what a multi-lingual page can be. If a page is multi-linguage, then it should describe that in the meta element & HTTP header & the language attributes in elements should change. The primary language attribute should be in the HTML element, not the body element, as this excludes elements containing language, such as the title. 
Hreflang. Some use in blogging. 
Structure of documents: in the past, tried to isolate material, so that content could be re-usable. Don't do that anymore to improve the flow from top to bottom. Will the usability person run tasks on docs? They are looking at the site at the moment, rather than specifically at the documents. AC the main document should be the techniques, rather than the techniques document pointing elsewhere. Dos & don'ts vs how-tos.

ACTIONS
See also GEO work items: http://www.w3.org/International/2003/plan.html
RI: send out note re holidays
RI: write up what was learned on linking between translated versions in a page.
TT: write up text re primary language & localisation, acknowledging that the latter was currently out of scope of the document.
AC: to circulate examples of multi-lingual pages.
All: email on other items in worklist - focus on language techniques document, because it needs to be finished.

http://www.bbc.co.uk/ - World Wide Wonderland

This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system. 
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. 
Further communication will signify your consent to this.

Received on Wednesday, 11 August 2004 15:06:40 UTC