-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: add localizable dictionary #358
Conversation
@annevk, I copy/pasta'ed a bunch from the Notifications spec, as suggested. But likely wrong. Can you please TAL. |
index.bs
Outdated
@@ -12750,6 +12750,43 @@ The {{VoidFunction}} [=callback function=] | |||
type is used for representing function values that take no arguments and do not | |||
return any value. | |||
|
|||
<h3>Locatlizable dictionary</h3> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be spelled "Lolcatlizable".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in marcoscaceres#1.
index.bs
Outdated
@@ -12750,6 +12750,43 @@ The {{VoidFunction}} [=callback function=] | |||
type is used for representing function values that take no arguments and do not | |||
return any value. | |||
|
|||
<h3>Locatlizable dictionary</h3> | |||
|
|||
A localizable member is a dictionary member that represents a bidirectional algorithm paragraph when displayed, as defined by the bidirectional algorithm’s rules P1, P2, and P3, including, for instance, supporting the paragraph-breaking behavior of U+000A LINE FEED (LF) characters. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably be an exported dfn, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, this should reference BIDI, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in marcoscaceres#1.
index.bs
Outdated
}; | ||
|
||
dictionary Localizable { | ||
DOMString lang; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why doesn't lang default to the empty string?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in marcoscaceres#1.
index.bs
Outdated
The {{lang}} member specifies the primary language for the localizable members in the prototype chain. Its value is a string. The empty string indicates that the primary language is unknown. | ||
Any other string must be interpreted as a language tag. Validity or well-formedness are not enforced. [[!LANG]] | ||
|
||
The {{dir}} member provides the higher-level override of rules P2 and P3 if has a value other than "auto". [[!BIDI]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if has?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in marcoscaceres#1.
index.bs
Outdated
Specification authors must specify in prose which member(s) of the inheriting dictionary serve as localizable members. It is RECOMMENDED that specification authors limit localizable member in the prototype chain of inherited dictionaries (ideally to one). | ||
|
||
<pre class="idl"> | ||
enum TextDirection { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this should be its own chapter if we're going to have this here? This might be useful on its own as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Canvas apparently has CanvasDirection, which uses "inherit" rather than "auto"... Good times.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add "inherit" to the enum and mark it as legacy?
Sent you a whole bunch of fixes in marcoscaceres#1. Didn't want to force push them to your branch, hence the pull request. |
* Split up Localizable and TextDirection. * Do most of the cross-linking. * Remove ES specific references to the "prototype chain". * Fix broken biblio references. * Add <small>semantic</small> line breaks.
Dunno, probably not worth the churn. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://notifications.spec.whatwg.org/#direction I think the current text doesn't stress enough that there could be multiple localizable members.
It also fails to account for multiple paragraphs of a single member.
It would also be good to see a PR that indicates how this changes Notifications.
index.bs
Outdated
Specification authors must specify in prose which [=dictionary members|member(s)=] | ||
of the inheriting dictionary serve as [=localizable members=]. | ||
|
||
It is recommended that specification authors limit the number of [=dictionary members=] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Specification authors should limit ..." is a little clearer than this. Per Infra we should avoid using "recommended".
index.bs
Outdated
Validity or well-formedness are not enforced. [[!BCP47]] | ||
|
||
The {{Localizable/dir}} member provides the higher-level override of rules P2 and P3 | ||
if it has a value other than <a for=TextDirection enum-value>"auto"</a>. [[!BIDI]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be more clearly made to apply to the localizable members.
index.bs
Outdated
of the inheriting dictionary serve as [=localizable members=]. | ||
|
||
Specification authors should limit the number of [=localizable members=] to one per dictionary, | ||
including in [=inherited dictionaries=] (if any). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this bit about inherited dictionaries ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It also fails to account for multiple paragraphs of a single member.
Said it's one or more. Does empty string count as one or zero?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure. You'd have to check the bidi algorithm I'm afraid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
np, checking
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm reading correctly, a paragraph is denoted by the presence of a paragraph separator. However, it says that we can also define what a paragraph means: "Paragraphs may also be determined by higher-level protocols: for example, the text in two different cells of a table will be in different paragraphs".
Like we could say that a member's value constitutes a paragraph? Dunno. Opinions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
? That seems better than each consumer having to define its own dictionary.
Yeah, I quite the typedef and the flexibility it gives. Do you want to add it?
As such I think web payments should use my LocalizableString proposal instead of its dictionaries inheriting from Localizable. (In fact we can remove Localizable entirely and just have LocalizedValue.) We can then say Notifications' design is old-school.
Would be great!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@domenic, we can probably merge LocalizedValue
into Localizable
, or is there some reason to have it inherit from Localizable
that I'm not seeing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what Payment Request would look like if using LocalizableString
(😍):
https://github.com/w3c/browser-payment-api/pull/455/files
Also, LocalizableString
means we can get rid of the "should" restriction, because now all localizable members now carry around their own lang
, dir
, and value
🎉.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want to add it?
As in, do I think it's a good idea? Yes. Do I want to do the work myself? Well, I will if I have to, but not this week; I was hoping you could :)
we can probably merge LocalizedValue into Localizable, or is there some reason to have it inherit from Localizable that I'm not seeing?
Nope, let's merge them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As in, do I think it's a good idea? Yes. Do I want to do the work myself? Well, I will if I have to, but not this week; I was hoping you could :)
Happy to!
index.bs
Outdated
@@ -12798,7 +12798,7 @@ The empty string indicates that the primary language is unknown. | |||
Any other string must be interpreted as a language tag. | |||
Validity or well-formedness are not enforced. [[!BCP47]] | |||
|
|||
The {{Localizable/dir}} member provides the higher-level override of rules P2 and P3 | |||
For the [=localizable member=], the {{Localizable/dir}} member provides the higher-level override of rules P2 and P3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be plural. It's not just one.
So just to check, this does not add any actual requirements on user agents in terms of the algorithms defined in the IDL spec, right? This is just some infrastructure to allow other specs to not have to keep redefining Localizable? |
Yes. |
Ok, new version is up with LocalizableString added. |
I'm not sure I agree with your discussion. We explicitly decided against making each thing localizable on its own for Notifications. It's also not a feature HTML offers for UI-exposed attributes. It's quite a lot of complexity for edge cases nobody is really convinced about. |
@annevk, which part are you not convinced about? Direction obviously doesn't affect us westerners much. But as a screen reader user, it's super frustrating when (web and native) apps don't label the language correctly for text. This causes foreign words to get read back in the system default, which is usually English (or worst, the OS just guesses - which is funny at first, but gets old pretty quick). I can provide you with example recordings if you would like. |
I'm not convinced developers will go through the trouble of getting the language of each of these correctly. And even if you went to those length it still wouldn't be perfect as multiple paragraphs in a single member can each have their own language or multiple languages, etc. So as with all engineering you need to make a tradeoff and what HTML and Notifications set the precedent for hasn't resulted in complaints. |
It's likely, but at least we would be giving developers the opportunity to try to do the right thing - even if not perfect. We've done a pretty good job in advocating for accessibility on the Web - we can do a better job at advocating that people add the appropriate members where it makes sense (specially if we can get them to experience how lousy things are when they don't!).
The number of people who this affects are underrepresented, so it's unfair to say that "we have not heard complaints". And end-users generally wouldn't know where to complain (do we expect them to make Bugzilla accounts?). Additionally, developers don't use a screen reader, so they are probably woefully ignorant of the lived experience of users who rely on them. Consider how bad the situation is just trying to get Safari to read The Intercept on iOS - you will hear it switch through numerous languages: Users (including me) don't need more of that in their life. My motivation is to use
Does a good job with elements, because you can be quite explicit by setting
My interest in making sure we add this is a result of me complaining and trying to make sure we fix it where we can in the platform. Again, I'm trying to fix it because I'm personally affected (as a developer and a user). |
What's the use case for multiple localized members each in their own language/direction where you don't have individual words in those localized members that would also need to be marked up to get it right? Again, this was discussed in depth in the past and has been discussed for HTML too (the attributes are equivalent with the case we're discussing here), including with members of the RTL community. |
Use cases are fairly limited, so I'm ok with dropping back to the simpler model: where dir/lang apply to "localizable members" identified in prose. |
I know extended attributes aren't designed for this purpose, but: dictionary PaymentItem : Localizable {
[Localizable] required DOMString label;
required PaymentCurrencyAmount amount;
boolean pending = false;
}; edit: extended attribute casing fixed. Thanks @annevk. |
Would like to hear the thoughts of @bzbarsky, @annevk, and @domenic on the below non-standard use of extended attributes so we can move ahead with the PR: dictionary PaymentItem : Localizable {
[Localizable] required DOMString label;
required PaymentCurrencyAmount amount;
boolean pending = false;
}; edit: extended attribute casing fixed. Thanks @annevk. |
I don't really understand @domenic's concern. You have to define in prose which members are the localizable members so there cannot be confusion among multiple DOMString members. Moving that coupling from prose to IDL seems fine (with an uppercase L in the extended attribute), but not an absolute necessity. |
I'd rather not use extended attributes for this. I guess we need to decide whether we want to support per-member localization like the i18n group suggests, or not, like @annevk suggests. That governs the shape of the solution. |
Their position changed since https://lists.w3.org/Archives/Public/public-web-notification/2012Jul/0039.html? Pointer appreciated. |
Noted.
Can't we somehow have both? E.g. have dictionary members whose dictionary FooBar : Localizable {
LocalizableString foo;
LocalizableString bar;
}; For example: { lang: "fr-CH", foo: { value: "hello", lang: "en-US" }, bar: "bonjour" }; where |
We can, but it's not clear to me the complexity is justified. |
@annevk, I'm not sure if this represents the position of the i18n wg, but this was the motivating comment: w3c/payment-request#327 (comment) |
Okay, we should probably first figure out implementer interest, especially if we turn this into something generic. Note that not providing it doesn't make the direction case impossible. You can still use Unicode code points for that. |
@annevk, I guess it depends on what you mean by implementer interest. If you mean that these members would be used in the UIs they are needed in, then, at least for Web Payments, I can confirm interest from Mozilla. The UI components we are building to enable payments are just HTML, so it's trivial to add these and they should "just work"(tm). I'm implementing the UI - so I will add them if this lands. In Web notifications (particularly as it pertains to Gecko hooking into OS-level notifications): I guess you investigated if these values can influence the rendering of notifications in various OSs? If yes, then that strengthens the case for standardization of these. If by implementation you mean doing something special at the Web IDL binding layer, I guess @bzbarsky is best positioned to answer that. |
@marcoscaceres what's the status around this now? |
Let's close. |
Bringing this over from w3c/payment-request#455 where it was suggested there that this be uplifted here.
I omitted the xrefs because:
Preview | Diff