Framework Document for i18n Guidelines 1.0

1 Introduction

The GEO Task Force has a mandate to produce guidelines in order to help make the internationalization aspects of W3C technology better understood and more widely and consistently used.

The near term intention of the GEO Task Force is to produce material that resembles the Techniques documents of the Web Content Accessibility Guidelines (WCAG) Working Group, but not its Guidelines. WCAG Guidelines are broad directives that are platform and technology independent. WCAG Techniques are detailed recommendations specific to a defined technology or set of technologies (eg. HTML or CSS).

This document describes plans both for source files used to store techniques and for documents that will be assembled from the information in the source files. The source files will likely only be viewed for editing purposes and will exist in the best format and organization that fulfills those requirements. From these source files we intend to derive a variety of user-related views. Each view may have its own requirements. A view should organize the material in the best way for the intended audience to find the information they are seeking. Note that the feasibility of an approach that reuses content in this way has yet to tested against the needs of real usage.

Other W3C groups have expressed interest in using the schema that is developed. Therefore, while the techniques documents are specifically created to meet GEO requirements, the structure is intended to be generalizable to other working groups and technologies.

It is worth noting that it is not currently expected that the recommendations produced by GEO will be tied in to conformance checking. This implies a significant difference from the approach taken to techniques development by the WCAG group. Much of WCAG's concerns centre on testability of techniques and relationships to guidelines, checkpoints and success criteria. None of these are currently planned for the GEO work.

2 Audience & scope

1. The goal is not to document all the information that exists on this topic, but rather to choose information of value to a particular type of audience and organize it in the most accessible way we can for that audience. The audience drives the development of material, it is not the information that drives it. The focus is always on producing something of practical use, rather than of an academic nature.

2. The section on major customer types at http://www.w3.org/International/geo/plan/geo-scoping.html provides a non-exhaustive but useful framework to help us consider possible target users.

3. We will focus on user agents of particular types, and running on specific platforms, and exclude older versions. The actual user agents considered will be a function of the expertise and interests of the group at the time when a deliverable is embarked upon, but should also cater for as wide an audience as possible.

4. Documents focused on a user will incorporate information about all technologies relevant to that user's task. For example, a document aimed at the developer of web pages will incorporate both X/HTML and CSS techniques side by side. The user should not be forced to look in two places to accomplish one task.

5. We will concentrate on information related to W3C technologies, and at most link to information on other technologies, trying to ensure that we point, in preference, to guidelines produced by the organization that owns the technology. We will also encourage organizations that own non-W3C technologies to provide guidelines themselves where necessary.

6. When dealing with an issue where available solutions are limited by the lack of support in user agents of certain aspects of W3C standards, we will:

   • propose a solution that can be implemented using currently-available technology

   • but also point out how the W3C standards when fully implemented can enable the better solution.

   The intention is to inform users of the full potential of the standards, and encourage user agent developers (perhaps through user lobbying) to implement the standards more fully.

7. Some topics, such as navigation, are not directly related to the implementation of W3C technologies in the way, say, XML encoding declarations would be. These topics are, however, relevant to the designer of an HTML or XML document. Whether such topics are addressed, and to what level, will be decided on a case by case basis. In some cases we may link to material on these topics created by others.

8. The needs and requirements of the localization industry should be reflected in the recommendations.

9. At a later date we may create generalized Guidelines in the WCAG sense, but the initial focus will be to provide technology-specific Techniques.

3 Usability

1. The techniques information will be highly structured to allow for condensation of the information to a simple, outline format. An outline format will reduce the potential of the material overwhelming the user, and allow the user to more easily get an overview of the content. It will not be used as a conformance related checklist.

2. Beginners should have access to the information with all examples and explanations included, and expert users using the outline should also be able to drill down to fully annotated material on a particular point for a topic with which they are less familiar. Between the simplest outline and the fully annotated material the user will typically be able to choose various levels of detail according to their preference.

3. Sections should include information about background or other pre-reading that would aid comprehension of the contents of the section.

4. As long as it is possible to define the mechanism well enough, it should be possible for a particular type of user to apply a filter to remove information not related to them. For example, a graphic designer may wish to remove all information related to scripting. The challenge in defining the mechanism is to ensure that no information pertinent to the user is omitted.

5. We will maintain a separate glossary that can be linked to from the text.

6. Substantial effort will be put into providing addtional resources for the reader of a technique. (We will consider also making the resources available directly from the Internationalization Activity web pages.)

   • We will provide or point to instructions, rather than just state rules. For example, configuring Apache web servers with correct HTTP Charset.

   • We will provide information about what versions of the W3C technology a technique is relevant to (eg. CSS1, CSS2, CSS2.1 or CSS3).

   • We will include information about user agent support for specific techniques. This will include information about which versions of which user agents amongst those we are tracking support a particular technique. It will also include notes indicating that a particular user agent supports the technique in a non-standard or particularly unusual way.

   • We should allow, if possible, the user to select from the list of user agents for which data is available the particular user agents for which they wish to see implementation related information.

7. We will clearly signpost techniques that are not yet fully implemented by in scope user agents.

8. We will not have the concept of WCAG Checkpoints in the near term.

9. We will maximize synergies with the WCAG efforts on techniques. This will provide us with the benefits of their experience, but also hopefully allow for a convergence of techniques in the future. As an ideal, we would like to be able to present a user with a set of combined i18n and WAI techniques, so that they do not need to look in two different locations for this information.

4 General architectural approach

1. The group will develop a set of XML source files referred to as repositories to house a collection of techniques. Each technique is a tersely-stated directive similar in level to the rules of the WAI techniques, and accompanying descriptions, explanations, references, etc. in a reusable format.

2. Each repository will be focused on a specific w3c technology, eg. there are different repositories for HTML and CSS.

3. There will be another Core repository for techniques that are not related to a specific technology, for example techniques relating to writing international English.

4. The repository files will likely only be viewed for editing purposes and will exist in the best format and organization that fulfills the needs of the editors.

5. Documents to be read by the user are called views and are created using XML source files referred to as templates. These templates provide headings and structure to meet the needs of the user, and at an appropriate level pull in content from a repository.

6. A template may repeat and reorder information in a repository, and may pull in information from several repositories, eg. a template aimed at HTML authors may pull content from HTML, CSS and Core repositories.

7. The structural information in a template will be hand-crafted. The template concept allows for very rapid prototyping or development of different views, depending on the needs of a particular user in a particular situation. It also provides easy but complete control over the ordering (and possible reuse) of techniques within a given view. The success of this approach will depend on a strict approach to structuring of information in a given technique so that it is reusable.

5 Structure of the techniques repository

1. Techniques must be highly structured and largely machine manipulable. They will exist in XML files conforming to the DTD/Schema described at http://www.w3.org/International/geo/techniques/documentation/documentation-dtd.html.

2. The structure should be general enough that it can be used by groups outside the GEO task force with minimal adaptation.

3. XSLT will be used to transform source files to XHTML in UTF-8 encoding. All localizable content in the XSLT files will be stored in separate XML files to facilitate localization.

4. Resource information will be stored in a separate repository to facilitate maintenance of links.

5. The structure of the source files will be as close to the structure of WCAG techniques as possible, to allow for future collaboration.

6 Deliverable types

1. We will publish the finished documents as W3C Notes, rather than W3C Recommendations, and produce updated versions on a regular basis (perhaps every six months).

7 Deliverables