publ-a11y
publ-a11y copied to clipboard
w3c
Localized placeholders
I believe there is an issue regarding how placeholders are handled in display statements. The technique documents contain basic concatenation instructions to handle placeholders:
This works fine for English, but we can't guarantee the placeholder will always be located at the end of the sentence. Here's an example translating this sentence in Japanese:
I suggest instead using actual placeholders in the strings. Positional placeholders (e.g. $1) are fine, but named placeholders are easier to understand by translators and less error-prone.
I don't know what type of placeholders does GitLocalize support, but it could be something easy-to-read like that:
The publication was certified on {date}
Related issue: https://github.com/w3c/publ-a11y/issues/460
I fully agree with @mickael-menu, to make these strings usable we would need interpolated strings as suggested above.
We also need to make sure that some of those strings (date for instance) are localized by the implementer. Displaying an ISO8601 date to the user, would make very little sense.
Editors agreed it would be the right path but stated that it was a significant change to make and decided to defer to the next version.
The topic was discussed in May 22, 2025 accessibility task force meeting. Kind attention implementers: @rickj , @gregoriopellegrino , @gautierchomel
Topic: Next steps for localized placeholders:
AvneeshSingh: https://github.com/w3c/publ-a11y/issues/688
CharlesL: when putting a date in a sentence, depending on the language you need to move the place of the word.
gpellegrino: instead of concatenating, it’s better to have a placeholder in the string, usually between brackets so it can be freely moved by the person localizing.
Hadrien: this came out when implementing in the readium mobile toolkits. It's possible to have more than one variable (day, month, year per example). Interpolating strings necessitate to have each piece in brackets.
AvneeshSingh: that mean a change in the JSON file and a warning for implementers.
Hadrien: we should recommend using interpolated strings and localized dates. As a user I can set up a language and a date format, that may be different. Implementers should not show raw data for dates, but format them to the user preference.
CharlesL: that also affects WCAG versions and levels.
mgarrish: for WCAG we can rely on official translations as they exist.
AvneeshSingh: Summing up, we understand that it is important task to work on soon and editors will figure out how to make that change.
One caveat regarding dates, I would discourage having each date component a separate placeholder variable. Modern OS and browsers already have date formatting APIs that use the convention preferred by the user and their region. However the technique documents could indicate the preferred style of formatting, e.g. from Apple's DateFormatter:
- short, e.g.
11/23/37 - medium, e.g.
Nov 23, 1937 - long, e.g.
November 23, 1937
I would discourage having each date component a separate placeholder variable […]
Do you mean that we should avoid something like {day}/{month}/{year}? If so, I agree that it should only use a single interpolated string ({date}) otherwise you can't handle localization preferences.
Some countries use month/day/year while others use day/month/year so it wouldn't make any sense breaking things down.
I'm not so sure about expressing a preference between the style of formatting either, since this is platform specific and could change over time.
Do you mean that we should avoid something like
{day}/{month}/{year}? If so, I agree that it should only use a single interpolated string ({date}) otherwise you can't handle localization preferences.
Exactly, I'm reacting to this quote from the meeting:
It's possible to have more than one variable (day, month, year per example). Interpolating strings necessitate to have each piece in brackets.
I'm not so sure about expressing a preference between the style of formatting either, since this is platform specific and could change over time.
For sure we can't control the exact format, but implementers will need to make this choice. Providing a recommendation on whether to display the date in abbreviated form or in full could be helpful.
Exactly, I'm reacting to this quote from the meeting
The quote is slightly misleading because that's not what I meant during the call.
What I wanted to point out is that we can't expect to always have a single placeholder (let's call it {variable}) in such interpolated strings, so we should design something that works for more than one (for example "This publication was certified by {certifier} on {date}")
For sure we can't control the exact format, but implementers will need to make this choice. Providing a recommendation on whether to display the date in abbreviated form or in full could be helpful.
Abbreviated forms are more likely to be confused with another date (01/02/2025 could be February 1, 2025 or January 2, 2025), which means that the extended forms are better. That said, some of them could include time, which is not really useful either.
I agree to use a unique placeholder for {date} and then let the implementer use the format he/she prefers, depending on the current localization (there are several libraries in different programming languages to do this).
