GEO Task Force
2nd Face-to-Face Minutes

Boston, March 2003

attendees - day 1 - day 2

The second Face-to-Face meeting of the GEO Task Force was held on Monday and Tuesday 3-4 March 2003, in Cam bridge, Massachusetts, at the W3C Technical Plenary.

See also the pages for agenda and meeting logistics.


Participating in person


Regrets received

Other WG Members

Minutes (day 1)

New WG members

We have had 3 more people apply for WG membership. Richard will process this on his return to the UK.

Review of Framework Document


We reviewed and raised the questions listed below for any areas where there was disagreement or need for more discussion.

  1. Who are we writing for and what are their needs?
  2. What user agents are we concerned about, and what versions?
  3. How much information about platforms and environments should be included?
  4. Do we want to include another technology, if so what?
  5. Should we document the way it is (given user agent limitations) or the way it should be?
  6. Do we directly include topics such as navigation (see Framework Document, Audience & scope, item #9)?
  7. How can we achieve guidelines that don’t give the impression that all sites must be localized?
  8. How can we optimize the outline for expert users who do not need as much background information?
  9. Do we filter? If so, what should we filter?
  10. How should we refer to user agent support? Should browser-specific information be in a separate place?
  11. Should we define basic terms?
  12. Should we create a template for each language set?
  13. Is there a process for keeping information up to date?
  14. Can two user agents be interoperable?
  15. Is this an appropriate way forward (see #2 and #3 on general architecture approach)?
  16. What will the deliverable be?
  17. Should we have more than one repository?
  18. How can we serve content in the user’s chosen language and explain how to do this on different servers?

There then followed a discussion about the questions...

Decision: Replace the use of the term 'database' with 'repository'.

Agreed: We should plan to move the framework document to the TR space as a working draft as soon as possible after the FTF.

We should add information about how our approach and reader needs are different from those of WCAG - ie. less checking, no legal constraints, variety of possible solutions, etc.

Agreed: People we are writing for are content authors, ie. implementors of HTML.

Agreed: We will focus on traditional user agents (browsers) for now, but not rule out the possibility of addressing PDAs and other devices for a later date.

Agreed: We will not include another technology for now, as we have plenty of work to do with HTML and CSS.

Agreed: Benefits statements to support techniques could be helpful.

Agreed: We should document the way things are (given user agent limitations) and the way they should be, but we must signal clearly where things do not currently work on browser implementations.

The group was concerned about users removing important information inadvertently through filtering.

Agreed: We will complete a full version first, without filters. Nor will we create new templates the reflect only partial information - such as for people who only want to implement pages in Arabic. We will however consider the possibility of using additional columns beside directives in the outline view to convey information about what scripts that directive is relevant to, as long as there is space.

Suggestion: To represent browser-specific information, use columns to the left of directives in the outline view. As we expand the number of browsers for which we have information, we could allow the user to select which columns are visible.

Suggestion: It may be a good idea to include Prereading. (e.g. "To understand this passage fully, please read the following:")

Suggestion: We could go to a W3C NOTE for stable documents, rather than follow the REC track.

Agreement: We should release an official updated version every 6 months.

Suggestion: We could add information about things you have to do, vs things that are good to do if you can, vs. things that are nice to do (eg. if you have an intern available).

Suggestion: In reference to item #10 in the Audience and Scope section of the Framework document, we may want to have different versions to serve the different needs of the localization industry.

Suggestion: Needs for localizability should be listed in the document.

Agreed: A collapsed view like that at showing only directives would be useful. We should call this an 'outline view', rather than a checklist view. It would also be useful to add additional information alongside each directive referring to applicability of particular browser versions. We could also allow the user to specify that they would like to see additional information such as cross-references and/or browser-specific notes. The user should also be able to also link to the the full document to see descriptions or resources related to a particular topic. The outline view would be for expert users.

Review of Authoring Techniques for XHTML & HTML

Agreement: Authoring Site Techniques should not be a checklist because people may think that this is all that needs to be done.

Suggestion: Provide a simple, outlined format for expert users.

Suggestion: Include clickable entities that show how to accomplish a task in a particular technology.

Agreement: Default should be how to do things that will work in both browsers, but we will also include how to do things that will only work in particular browsers/os (e.g. vertical text).

Agreement: Task is the most important thing for us to focus on (i.e. what users are trying to do). The point is how best to help the user.

Definition of Target Audience

User Categories (list may expand):

Potential Needs Analysis:

Agreement: Assume no knowledge of I18N.

Agreement: Assume knowledge of basic HTML.

Note: We should not use the word scripts to refer to languages, as it may be confusing for programmers.

Presentation by QA Representatives: Olivier Thereaux and Karl Dubost

QA (Quality Assurance) committee is working to improve W3C specifications by designing a family of guidelines that improve practices and reduce cost of development.

Success stories: DOM, SOAP, SVG, UAAG

The QA group has developed a QA Matrix (i.e. a view of all W3C projects from a QA perspective).

Suggestion: Each working group in the W3C should designate a QA liaison.

Advice: Provide small tidbits of information through e-mails and news so that people keep the group and its outreach methods in mind.

Advice: Make guidelines and recommendations easy to use

Advice: Classify data in types and targets.

Advice: Focus on target audience – clarify scope.

Advice: Explain to the user - Why should this be read? Who should read it? How do you know that you have implemented it correctly?

Advice: Describe test suite and give it to others to incorporate into their test suites.

WAI Meeting: Judy Brewer, chair

Examples of successful WAI initiatives:

3 important WAI outreach activities:

  1. Evaluating sites for usability
  2. Understanding how people use the Web – human perspective
  3. Making the case for accessibility

WAI question: What is a better term for non-native (sic.) languages? This question will be revisited offline.

WAI offer: The I18N GEO group may insert I18N concerns into the WAI guidelines.

Proposal: Establish a horizontal coordination group between WAI and I18N GEO with the possibility of scheduling a group meeting by phone or face-to-face.

Minutes (day 2)

Review of Table of Contents

Question: Are things easy to find? Is it comprehensive?

Suggestion: Include what to look for in choosing an editor – we could provide a link to this information, as it is not in our charter.

Suggestion: Include advice on how to make sure the user did not get encoding wrong.

Note: Missing direct reference to using NCR's. This could go in the index.

Question: If you have search engine do you need an index?

Agreement: Yes, an index would be helpful.

Suggestion: Link elements can be used for pointing to alternative views of a page.

Note: Ask WCAG about correct terminology - document or page?

Answer: WCAG uses the term 'content', in order to include dynamic entities.

Suggestion: In item #3, we should add a section on including non-Latin characters in an internationalized page.

Question: What is the best way to incorporate background information?

Suggestion: Russ brought up a concern about item #8, Tables – decided to return to this later.

Suggestion: Regarding item #16, when talking about data for different locales, make sure that we mention both display and recognition of input data.

Question: Where should we address frames used for navigation?

Agreement: Use of frames for navigation could fall under item #1.3, International Layout Considerations.

Suggestion: In some cases we may recommend or discourage certain technologies.

Suggestion: Tex and Russ proposed that the group keep a “to do” list separate from the final presentation.

Question: Should file management/organization be added to the TOC?

Suggestion: We may want to provide a document that presents a suggested sequence for users, but not yet.

Agreement: In regard to content generation, group members provide content to editors, who process it for publication.

Proposed table of contents for HTML Authoring View

1 Document structure & metadata
    1.1 Internationalizing the page header
    1.2 International layout considerations
	talk about frames
    1.3 Document structure
    1.4 Sentence fragmentation and re-use
    1.5 Ordering text
    1.6 Separating semantics from presentation

2 Character sets, character encodings and entities
    2.1 Choosing a page encoding 
    2.2 Specifying the page encoding
    2.3 Referring to specific characters
    2.4 Specifying the encoding of a link destination

3 Fonts
    3.1 Choosing & specifying fonts
    3.2 Dealing with undisplayable characters
    3.3 Installing multilingual fonts
    3.4 Pages containing multiple languages
4 Specifying the language of content
    4.1 Identifying the primary language 
    4.2 Identifying language change
    4.3 Specifying the language of a link destination
    4.4 Specifying language codes

5  Handling bidirectional text
    5.1 Setting directionality for an entire document
    5.2 Changing directional properties for a part of the text
    5.3 Overriding the Unicode bidirectional algorithm
    5.4 Handling parentheses & other mirrored characters
    5.5 Enabling mirroring of layout

6 Supporting vertical text

7 Text formatting
    7.1 Emphasis
    7.2 Acronyms & abbreviations
    7.3 Quotations
    7.4 Ruby

8 Lists
    8.1 Implementing language-specific list markers

9 Tables
    9.1 Mirroring tables in bidirectional text
    9.2 Specifying table dimensions
    9.3 Alignment issues
    9.4 (Other stuff)

10 Links
    10.1 Keyboard access to links
    10.2 Using non-ASCII characters in link targets
    10.3 Including encoding and language information in links
    10.4 Linking in a multilingual site

11 Objects
    11.1 Determining the runtime locale for an object
    11.2 Dealing with embedded objects with different encodings

12 Images
    12.1 Creating culturally appropriate graphics
    12.2 Using text in graphics
    12.3 Using image maps
    12.4 Using color
    12.5 Dealing with directional bias in graphics
    12.6 Creating localisable graphics

13 Handling data that varies by locale
    13.1 Date & time
    13.2 Numbers
    13.3 Currency, 
	telephone numbers, 
	personal names, 
	paper sizes...

14 Forms
    14.1 Dealing with character sets & encodings
    14.2 Keyboard access to forms
    14.3 Creating culturally appropriate forms
    14.4 Creating buttons

15 Keyboard shortcuts

16 Writing source text
    16.1 Writing clear, understandable text
    16.2 Using metaphors, examples and humour
    16.3 Using abbreviations & acronyms

17 Text formatting
    17.1 Emphasis
    17.2 Acronyms & abbreviations
    17.3 Quotations
    17.4 Ruby
    17.5 Use of pre text
    17.6 Visual style conventions

18 Navigation
    18.1 Navigating to the preferred localised web site
    18.2 Implementing international contact pages

19 File management

20 Supplying data for localisation

Note: we still need to review the topics relating specifically to CSS and add these.

Review of Richard’s Content

Suggestion: Guideline might consist of multiple steps.

Suggestion: There could be a rationale section in addition to a “just do it” section.

Suggestion: Arabic examples should be used in addition to Hebrew to show impartiality.

Suggestion: Text that is visually ordered should be converted to logically ordered.

Suggestion: Steps should be clear and annotated.

Action: Tex agreed to write bullet items to outline 5.1 for Richard.

Action: Tex and Martin decided to work together to resolve CSS issues in item #5.2.

Miscellaneous discussion points

Missing sections

Agreed: We should add a guidelines section about how to display non-ASCII examples

Suggestion: Add section on how to handle printing issues.

Handling non-ASCII examples in the text

Agreed: We will provide upper and lower case Latin examples to show Arabic and Hebrew directionality in addition to Arabic and/or Hebrew examples.

Agreed: We will link to a .pdf version to show examples of non-ASCII for those who have display problems.

Editorial approach

Agreed: Content submitters should not expect what they submit to be reproduced without change in the finished document. Editors will take the ideas from the submitted content and write the final text. Submitters should send in ideas: principally, rules, points to go in the descriptions, and resource pointers. It is not necessary to use the HTML template supplied earlier, but you can if you want to.

Note that at a later stage contributors may markup up versions of the actual document to suggest edits.

Review of Martin’s Content

Suggestion: We could include an item that says to not rely on char set, as it may not work for return of character encoding.

Recommendation: Use xforms although this does not always work. Because it is unreliable, it would be a good idea to get confirmation from the user.

WCAG meeting: Wendy Chisholm, chair

WCAG strives for guidelines that are:

Checklist is provided with checkpoints that are objective, testable, and technology agnostic.

Goal: Someone developing a page should not have to look in separate places for guidelines.

IBM representative question 1: What is the correct way of handling different encore?

IBM representative question 2: Are there guidelines on the degree of difficulty in providing translated versions of different languages?

WCAG Plans: Develop a resource page on how to annotate markup to reduce ambiguities –will cc this to us.

Terminology Question: WCAG uses the word content instead of page or document. User agent is used instead of browser.

Suggestion: I18N review of WCAG material - WCAG review of I18N material.

Suggestion: Take two documents and get them to satisfy both WCAG and I18N guidelines in a joint effort - proposed by Tex.

Agreement: We will keep PF in the loop.

Commitment: Identify points of convergence between the work of I18N GEO and WCAG, and engage in active joint exploration.

The chair of the Internationalization Working Group is Richard Ishida (W3C). The chair of the Web Services Task Force is Addison Phillips (webMethods, Inc.). The staff contact of the Internationalization Working Group and the Web Services Task Force is Martin Dürst ( The chair and staff contact of the the GEO Task Force is Richard Ishida (

Valid XHTML 1.0! Valid CSS! $Id: ftf200211.html,v 1.5 2002/10/25 21:32:48 rishida Exp $