The W3C Internationalization Activity uses github for document development. This page provides guidelines to help people contribute content that matches the standard styling and keeps the documents in a state that keeps the publication process straightforward.
The i18n WG works with 3 main types of page: article pages, site pages such as this one, and respec documents. They each use different javascript and style files.
If you have comments or suggestions about how to improve this page, feel free to raise a Github issue.
See also the guidelines for working with github.
General principles for editing HTML
You should always bear in mind the following when creating content:
- HTML pages must always be valid! Use the W3C validator.
- Use HTML5 markup.
- HTML pages must always use the UTF-8 character encoding, and this encoding should be declared at the top of the file.
- HTML pages must also always declare the language of the document as a whole using a
lang
attribute in thehtml
tag. A range of text in another language inside the document should be tagged for language too, using thelang
attribute. - When using bidirectional script content, always wrap all opposite-direction phrases in markup using a
dir
attribute. - When committing changes, use clear and simple descriptions of changes. It should be possible to use the commit list as a change log for the document, so think in these terms when wording the initial line of your commit.
We recommend adding the standard i18n CSS rules in a file called local.css
. These rules can be found below.
Important: Only make minimal changes to the source code. If you commit an update that has lots of formatting changes in the source code, it obscures the actual substantive changes in the github diff. You must use an editor that doesn't automatically re-layout the source text each time you make changes. If you do want to tidy the source text, do so as a separate commit, with no substantive changes applied, and describe the commit so that people are aware that it is just a source tidy.
General markup guidelines
Javascript & CSS files
New articles must include the following:
- javascript/doc-structure/article-2022.js
- javascript/articletoc-2022.js
- style/article-2022.css
New site pages must include the following:
- /i18n-drafts/javascript/doc-structure/sitepage-2022.js
- /i18n-drafts/javascript/articletoc-2022.js
- /i18n-drafts/style/sitepage-2022.css
New articles and site pages with syntax highlighting must include the following:
- javascript/prism.js
- style/prism.css
We use relative links so that pages can be viewed without an internet connection.
Respec provides the appropriate scripting and styling when working in that context.
Source code
It isn't required, but it's easier to find things in the source code if you leave several blank lines before each section tag, and single blank lines between block elements such as p, figure, blockquote, etc.
Headings
Do not supply numbering for section headings. These will be provided automatically by scripting.
An h1
..h6
element should be used for headings, and should always be a direct child of a section
element. The section
element should have an id
. The h* element should not have a link around the heading (self links are added automatically by scripting).
<section id="mylinkid">
<h3>My header text</h3>
...
</section>
The current styling for TR documents makes it often difficult for readers to quickly find section headings. Use the styling suggested below in your local.css file in order to open up the space between sections.
To refer to a section from the text
In Respec: use[[[#section_id]]]
, where section_id is the id of the section you are pointing to. (An alternative is to use <a href="#section_id"></a>
, but the previous approach is better because you are able to see the id in wysiwyg source or if the link fails.)
In i18n articles: use <a class="secref">section_id</a>
, where section_id is the id of the section you are pointing to. (Only works with articles that use the latest javascript includes.)
The paragraph containing the pointer will be updated automatically with a link to the section you are pointing to, and the link text will be the section heading.
Figures
Put pictures, tables, examples, and the like in figure
markup. Use the figcaption
element when you want a caption. (Caption use is encouraged.)
To refer to a figure
from the text
In Respec: use [[[#figure_id]]]
, where figure_id is the id of the figure you are pointing to. (An alternative is to use <a href="#figure_id"></a>
, but the previous approach is better because you are able to see the id in wysiwyg source.)
In i18n articles: use <a class="figref">figure_id</a>
, where figure_id is the id of the figure you are pointing to. (Only works with articles that use the latest javascript includes.)
In both cases, the markup will be replaced by a link to 'Figure XX' when the page is viewed. The Figure number will be updated automatically as new figures are added.
Notes
To create a block-type note add class="note"
to the paragraph if a single para note, or use a div class="note"
around the note if it contains multiple paras or blocks.
For editor's notes, put class="issue"
on a p
, div
or span
around the text you want to be the editor's note.
Run-in headings
Sometimes it's not necessary to create a new section and heading, but you may want to highlight a word or sentence at the start of a series of paragraphs. To do this, use the following markup.
<span class="leadin">highlighted text goes here</span> Rest of paragraph follows...
Abbreviations and acronyms
Use the abbr
element for both of these. Spell out the full form in the title
attribute.
Syntax highlighting
In Respec: use triple-backticks to create code blocks.
```css
p { color: red }
```
In i18n articles and site pages: use a pre
element with a code
element inside to mark up a code block for syntax highlighting, like so:
<pre><code class="language-css">p { color: red }</code></pre>
Inline code snippets are done like this:
<code class="language-css">p { color: red }</code>
Note: you have to escape all <
and &
characters inside code
elements (code blocks and inline snippets) with <
and &
respectively. If you have large portions of HTML code, you can use the Unicode code converter to escape these characters.
Lists
A colon should be used for a sentence that leads into the list.
If a list is expressed as a single sentence each list item should begin with a lower case letter and end with a comma or ", and". The last list item should end with a full stop.
Example:
Every W3C specification MUST:
- conform to the requirements applicable to specifications,
- specify that implementations MUST conform to the requirements applicable to software, and
- specify that content created according to that specification MUST conform to the requirements applicable to content.
Otherwise, each list element should begin with an uppercase letter and end with a full stop.
Example
Some aspects of Unicode that require additional specification for the Web include:
- Choice of encoding forms (UTF-8, UTF-16, UTF-32).
- Counting characters, measuring string length in the presence of variable-length encodings and combining characters).
- Duplicate encodings (e.g. precomposed vs decomposed).
- Use of control codes for various purposes (e.g. bidirectionality control, symmetric swapping, etc.).
Change markup
To show changes to the text use ins
and del
. However, remember that if you do commits carefully, such markup is not needed. People will be able to see the changes by looking at the diff for the commit on the Github site.
Marking up inline content
Codepoints
Use the following markup to represent a character. For certain languages, it may be necessary to style the bdi
element with a font-family
and font-size
.
<span class="codepoint" translate="no"><bdi lang="XX">&#xXXXX;</bdi><code class="uname">U+XXXX UNICODE_CHARACTER_NAME</code></span>
For example:
<span class="codepoint" translate="no"><bdi lang="en">é</bdi><code class="uname">U+00E9 LATIN SMALL LETTER E WITH ACUTE</code></span>
That will produce: éU+00E9 LATIN SMALL LETTER E WITH ACUTE
.
The easiest way to create this markup is to choose an appropriate character app, type or paste the character in the large box, and click on Character markup. Then click on the icon to the right to copy the result to your clipboard. Note that the character app can also convert characters to NFD using the control lower down the page.
A similar approach can be used for character sequences (and can also be produced easily using the character apps). The normal pattern is:
<span class="codepoint" translate="no"><bdi lang="XX">&#xXXXX;&#xYYYY;</bdi><code class="uname">U+XXXX UNICODE_CHARACTER_NAME</code> + <code class="uname">U+YYYY UNICODE_CHARACTER_NAME</code></span>
For example:
<span class="codepoint" translate="no"><bdi lang="fr">é</bdi><code class="uname">U+0065 LATIN SMALL LETTER E</code> + <code class="uname">U+0301 COMBINING ACUTE ACCENT</code></span>
That will produce: éU+0065 LATIN SMALL LETTER E
+ U+0301 COMBINING ACUTE ACCENT
.
When referring to an invisible character you may want to simply omit the bdi
element, or you can use an image. The image should be stored in a local directory. It is important to style the size of the image, so that it fits inline (especially when using an SVG image). The default style sheet applies a height of 1.6em, but this can be changed inline where needed.
<span class="codepoint" translate="no"><img alt="NBSP" src="images/00A0.png"><code class="uname">U+00A0 N0-BREAK SPACE</code></span>
That will produce:
U+00A0 N0-BREAK SPACE
.
Other inline markup
The following table suggests conventions for marking up inline content. The presentation column applies to the English version. Any translated version may change the presentation (eg. a Japanese version may substitute underlining for bold).
Type of in-line content | Example | Markup to use |
---|---|---|
emphasis (general) | In keyboard input it is not always the case that... | em |
emphasis (stronger) | you must absolutely not do that! | strong |
new term introduction | The set of characters is called a repertoire. | dfn id="def_<termName>" title="<termName>" |
reference to a term definition | The repertoire of UTF-8 includes all characters you're likely to need. | a class="termref" href="#def_<termName>" |
document title | see Requirements for String Identity Matching. | cite |
quoted term | The word character is used in many contexts. | span class="qterm" |
quoted term / phrase expressing dubious usage | ie. numeric positions within a string | span class="quote" |
quoted text | such as ...as it may from time to time be revised or amended. |
q |
quoted character (refers to typically one, but occasionally more, specific characters). | The character ç is common in French. | span class="qchar" |
quoted sample output (cf. HTML SAMP) | The string artículo is subject to different representations | samp |
quoted code | sucçon |
code translate="no" |
quoted keyboard input (cf. HTML KBD) | a user typing çé on a traditional French-Canadian keyboard | kbd |
element name | a user agent that looks for artículo elements |
span class="el" translate="no" |
attribute name or value | the section element |
code class="kw" translate="no" |
function name | The doit function returns interesting results. |
code class="kw" translate="no" |
key word in a markup or programming language | the IANA charset value |
code class="kw" translate="no" |
variable name | var | |
conformance related word based on rfc2119 | All references to Unicode MUST refer to... | span class="rfc2119" |
acronyms & abbreviations | More and more APIs are defined, | abbr title="..." |
Unicode name | Use U+0338 COMBINING LONG SOLIDUS OVERLAY for that. | span class="uname" |
an URL that doesn't have a link on it | https://github.com/w3c/repoName/ | <span class="url">https://github.com/w3c/repoName/</span> |
If you use b
or i
tags, use a class name with them, so that semantically different
usages can be styled differently (esp. for documents with
translations!).
Suggested styling for local.css
The following styles can be used as the base for the local.css
file. They contain style rules for the approaches mentioned in this styleguide.
h2 {
margin-top: 3em;
margin-bottom: 0em;
}
.head h2, #abstract h2, #sotd h2 {
margin-top: 0;
}
h3 {
margin-top: 3em;
}
h4 {
font-size: 100%;
font-weight: normal;
color: #005a9c;
margin-top: 2em;
}
.leadin {
font-weight: bold;
}
ins {
background-color: #99FF99;
text-decoration: none;
}
del {
display: inline;
color: silver;
}
figure {
margin-bottom: 2em;
text-align: center;
}
figcaption {
text-align: center;
margin: 0.5em 2em;
font-style: italic;
font-size: 90%;
}
.figno:after {
content: ':\00A0 ';
}
a.termref:link {
color:#C60;
text-decoration:none;
border-bottom: 1px dotted #FC0;
}
a.termref:hover {
color:#C60;
text-decoration:none;
border-bottom: 1px dotted #FC0;
}
a.termref:visited {
color:#C60;
text-decoration:none;
border-bottom: 1px dotted #FC0;
}
a.termref:active {
color:#C60;
text-decoration:none;
border-bottom: 1px dotted #FC0;
}
.qterm:before, .qchar:before { content: "'"; }
.qterm:after, .qchar:after { content: "'"; }
.quote:before { content: '"'; }
.quote:after { content: '"'; }
code {
color: #A52A2A;
font-family: Consolas, "Andale Mono", "Lucida Console", "Lucida Sans Typewriter", Monaco, "Courier New", monospace;
font-size: 100%;
}
samp, kbd {
font-family: Consolas, "Andale Mono", "Lucida Console", "Lucida Sans Typewriter", Monaco, "Courier New", monospace;
font-size: 100%;
}
.codepoint bdi {
line-height: 1em;
font-size: 1.25em;
padding-inline: 0.25em;
}
.codepoint img {
height: 2em;
margin-inline: 0.25em;
vertical-align: bottom;
}
.uname {
font-family: Arial, monospace;
font-size: 0.75em;
letter-spacing: 0.03em;
color: brown;
}
Creating a new article
To create a new article take an existing page's code as a template and modify it as needed.
Getting reviews
The process we normally follow is:
- Once you have a basic start on the text, publish the article to GitHub and add an item to the weekly meeting agenda and ask people to give thoughts on the direction you are heading in. Tell them not to comment on typos or finer editorial points at this stage: the key is to check that the overall thrust of the content and headings are going in the right direction.
- Once you have a fair copy of the article, building in the feedback from step one, raise another agenda item for the weekly meeting to ask for detailed comments and to propose that the article be sent out for wide review. The WG may ask for substantive changes, in which case you'll need to address the feedback and resubmit for internal review. Alternatively, the group may raise a few smaller points and agree to move the article to wide review once those edits have been made.
- Submit the article for wide review by asking for feedback by a given date of the i18n blog (home page news), and in our social media feeds. Copy the pattern of existing announcements, where possible. You should ask for feedback on the version uploaded to GitHub. We haven't often done it in the past, but it might be good to also sent notifications to other groups who are directly concerned with the topic of the article.
- Once the specified date has passed, make any necessary changes, check for and fix any validation errors, and go back to the WG telecon to check whether anyone objects to final publication. (In rare cases, you may need to cycle back through the process if substantial edits were made.)
- Publish the final article to GitHub and also to CVS.
- Add the article to the articlelist-data/translations.js file and upload to CVS. (This file is not uploaded to GitHub.)
- Announce the new article via the i18n home page and social media channels.