Decide what to do about the i18n pages #90
Comments
|
Just reproducing my comments here as they don't need to appear in a non-public repo:
The framework tool does not assume a particular set of headings or structure. What it assumes is that:
OK, the question this triggers for me is: "does maturity really mean something here?". Also, this "evergreen" information would need to be manually entered in the description of the feature. This is already envisioned, see https://github.com/w3c/media-web-roadmap/issues/6
I'm fine with a different color. Doesn't "orange" convey a sense of incompletion, though? The tool should be able to gather the "expected to become a Rec" or not information automatically to select the appropriate color otherwise.
Hmm, what does "Early WD" mean? In my mental model, I would put it before FPWD. Also, how could the framework automatically detect whether a document is an early WD or a WD?
That seems good to me. This info can be automatically retrieved, with the exception of the Japanese version of the "Requirements for Japanese Text Layout" document, which would need to be specified somehow in the description of the feature. I can easily imagine a system where, at the roadmap level, you specify (in some settings file or JS object) what you'd like to see in the column. All in all, this suggests more flexibility in the way one can specify the table structure, which sounds needed in any case. |
This update gets rid of the HTML table templates that did not serve any useful
purpose, since the logic that goes with a table needs to be implemented in
the code one way or the other. Said differently, the code needs to know the
structure of the tables it is to generate, so hiding that structure in an HMTL
template is useless and error-prone.
The table column headers now need to appear in translation files in a `columns`
property (see `translations.json` for reference).
The types of tables and the columns to display for each of them can now be
customized on a roadmap per roadmap basis, in the `toc.json` file, in a
`tables` property that lists the columns to use per type of table. This
mechanism can be used to override the default tables or to create new types
of tables.
For instance, to add the "group" column to the columns generated in
"well-deployed" sections, one can simply add the following to the `toc.json`
file:
```json
{
"tables": {
"well-deployed": ["feature", "spec", "group", "maturity", "impl"]
}
}
```
I created a new "versions" type of column, which should eventually become what
@r12a needs in w3c#90 (not quite the case now because the framework does not
yet know how to gather the Editor's Draft and the GitHub repo of a spec)
This update gets rid of the HTML table templates that did not serve any useful
purpose, since the logic that goes with a table needs to be implemented in
the code one way or the other. Said differently, the code needs to know the
structure of the tables it is to generate, so hiding that structure in an HMTL
template is useless and error-prone.
The table column headers now need to appear in translation files in a `columns`
property (see `translations.json` for reference).
The types of tables and the columns to display for each of them can now be
customized on a roadmap per roadmap basis, in the `toc.json` file, in a
`tables` property that lists the columns to use per type of table. This
mechanism can be used to override the default tables or to create new types
of tables.
For instance, to add the "group" column to the columns generated in
"well-deployed" sections, one can simply add the following to the `toc.json`
file:
```json
{
"tables": {
"well-deployed": ["feature", "spec", "group", "maturity", "impl"]
}
}
```
I created a new "versions" type of column, which should eventually become what
@r12a needs in #90 (not quite the case now because the framework does not
yet know how to gather the Editor's Draft and the GitHub repo of a spec)
Features initially proposed in w3c#90. W3C specs are automatically flagged as informative when they contain only informative content or when they will be (or have been) published as a Note. Specs can also be flagged as "evergreen", which means that, regardless of their exact status on the Rec-track (or elsewhere), they can be considered fit for reference. This is roughly equivalent to the notion of a Living Standard in WHATWG. These settings are used to adjust the maturity icon being rendered. Notably: - regardless of their exact maturity status, evergreen specs use a green "REF" (for "Reference") icon. - informative icons are in dark grey to convey the fact that the spec does not define normative content. Note these colors do not match those proposed in the initial issue. This can be adjusted later on if needed.
Features initially proposed in #90. W3C specs are automatically flagged as informative when they contain only informative content or when they will be (or have been) published as a Note. Specs can also be flagged as "evergreen", which means that, regardless of their exact status on the Rec-track (or elsewhere), they can be considered fit for reference. This is roughly equivalent to the notion of a Living Standard in WHATWG. These settings are used to adjust the maturity icon being rendered. Notably: - regardless of their exact maturity status, evergreen specs use a green "REF" (for "Reference") icon. - informative icons are in dark grey to convey the fact that the spec does not define normative content. Note these colors do not match those proposed in the initial issue. This can be adjusted later on if needed.
The framework can now render a "See also" column that contains useful links to resources related to the specification, notably: - a link to the Editor's Draft - a link to the repository that contains the Editor's Draft - specific links defined in the description of the spec. The "See also" column is only rendered in the (currently unused) `versions` type of summary table. The exact links that need to be rendered can be customized in the `toc.json` file. The README explains how to customize the summary tables. See related need expressed in w3c#90 NB: The framework more or less already supported a `versions` column but that wasn't flexible enough, and name seemed badly chosen.
The framework can now render a "See also" column that contains useful links to resources related to the specification, notably: - a link to the Editor's Draft - a link to the repository that contains the Editor's Draft - specific links defined in the description of the spec. The "See also" column is only rendered in the (currently unused) `versions` type of summary table. The exact links that need to be rendered can be customized in the `toc.json` file. The README explains how to customize the summary tables. See related need expressed in #90 NB: The framework more or less already supported a `versions` column but that wasn't flexible enough, and name seemed badly chosen.
|
@r12a I believe the framework now supports most of the features you requested, although with a couple of nuances. Looking back at your initial list:
That was already possible. You can group stuff whichever way you want. To create custom summary tables at the end of these sections, check Customizing summary tables.
In the description of the spec, you can now add an
I settled on dark grey instead of orange to convey the fact that a spec is "informative", because orange suggests the spec is not final, at least for me. A spec is informative if it only contains informative content or if it has a NOTE endpoint. The information is automatically extracted from the W3C API for W3C specs. For other documents, use the Note dark grey is also used for evergreen specs that are informative (so they won't show in green).
That is not done because:
If you feel that's still needed, please clarify!
While not enabled by default, you can tell the framework to render a |
[This is probably relevant to WAI and other horizontal activities, and maybe more groups.]
Back in March i fleshed out a draft for i18n requirements. Basically it reproduces the page at https://www.w3.org/International/layout. Here's the link
https://r12a.github.io/media-web-roadmap/i18n/index.html
Here's what i said at the time:
There's a response to this from Francois on a non-public repo (https://github.com/w3c/team-strat/issues/43#issuecomment-285656996).
Since the roadmap concept is gaining momentum again, i'd like to discuss what to do wrt i18n pages.
The text was updated successfully, but these errors were encountered: