How much information about platforms and environments should be included?

Do we want to include another technology, if so what?

Should we document the way it is (given user agent limitations) or the way it should be?

Do we directly include topics such as navigation (see Framework Document, Audience & scope, item #9)?

How can we achieve guidelines that don’t give the impression that all sites must be localized?

How can we optimize the outline for expert users who do not need as much background information?

Do we filter? If so, what should we filter?

How should we refer to user agent support? Should browser-specific information be in a separate place?

Should we define basic terms?

Should we create a template for each language set?

Is there a process for keeping information up to date?

Can two user agents be interoperable?

Is this an appropriate way forward (see #2 and #3 on general architecture approach)?

What will the deliverable be?

Should we have more than one repository?

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 http://www.w3.org/International/geo/upload/2003/02/html-authoring-ch.html
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):

Programmers

Information architects

Text authors

Graphic designers

Localizers

Potential Needs Analysis:

Handling writing systems – display and input

Casting culturally appropriate graphics

Locale information format issues (e.g. currency, date, time, etc.)

Sorting

Fonts and complex renderings

Text justification

Text indentation

Layout

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:

FAQ sheet for Web content accessibility guidelines

Examples of how to make sites accessible

Templates of accessible pages

Gallery section (showcase of accessibility success stories)

Modules for accessibility training

Resources

3 important WAI outreach activities:

Evaluating sites for usability

Understanding how people use the Web – human perspective

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.

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:

operable

navigable

understandable

perceivable

robust

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: 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 (duerst@w3.org). The chair and staff contact of the the GEO Task Force is Richard Ishida (ishida@w3.org).