$Id: ftf200211.html,v 1.5
2002/10/25 21:32:48 rishida Exp $
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.
We have had 3 more people apply for WG membership. Richard will process this on his return to the UK.
We reviewed http://www.w3.org/International/geo/framework/ and raised the questions listed below for any areas where there was disagreement or need for more discussion.
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.
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.
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.
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 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.
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.
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,
measurements,
addresses,
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.
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.
Suggestion: Provide practical advice (i.e. if an HTML spec is not reliable we should not espouse it).
Suggestion: We should establish guidelines for display of examples – we may need to use .gif's of .pdf's.
Suggestion: Add an explanation of how to handle examples in different scripts.
Suggestion: Add section on how to handle printing issues.
Agreement: We will provide upper and lower case Latin examples to show Arabic and Hebrew directionality in addition to Arabic and/or Hebrew examples.
Agreement: We will link to a .pdf version to show examples in order to avoid language display problems.
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 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 (duerst@w3.org). The chair and staff contact of the the GEO Task Force is Richard Ishida (ishida@w3.org).