WIP: add localizable dictionary #358

marcoscaceres · 2017-05-02T09:34:13Z

Bringing this over from w3c/payment-request#455 where it was suggested there that this be uplifted here.

I omitted the xrefs because:

like to get the prose right first.
I don't know how to do it in BS yet.

Preview | Diff

marcoscaceres · 2017-05-02T09:38:17Z

@annevk, I copy/pasta'ed a bunch from the Notifications spec, as suggested. But likely wrong. Can you please TAL.

annevk · 2017-05-02T10:38:38Z

index.bs

@@ -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>


Should be spelled "Lolcatlizable".

Fixed in marcoscaceres#1.

annevk · 2017-05-02T10:39:05Z

index.bs

@@ -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.


This should probably be an exported dfn, no?

Also, this should reference BIDI, right?

Fixed in marcoscaceres#1.

annevk · 2017-05-02T10:40:48Z

index.bs

+};
+
+dictionary Localizable {
+  DOMString lang;


Why doesn't lang default to the empty string?

Fixed in marcoscaceres#1.

annevk · 2017-05-02T10:41:10Z

index.bs

+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]]


Fixed in marcoscaceres#1.

annevk · 2017-05-02T10:42:14Z

index.bs

+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 {


Maybe this should be its own chapter if we're going to have this here? This might be useful on its own as well.

Canvas apparently has CanvasDirection, which uses "inherit" rather than "auto"... Good times.

Should we add "inherit" to the enum and mark it as legacy?

tobie · 2017-05-02T13:47:19Z

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.

annevk · 2017-05-02T14:27:11Z

Should we add "inherit" to the enum and mark it as legacy?

Dunno, probably not worth the churn.

annevk

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.

annevk · 2017-05-02T14:30:13Z

index.bs

+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=]


"Specification authors should limit ..." is a little clearer than this. Per Infra we should avoid using "recommended".

annevk · 2017-05-02T14:34:55Z

index.bs

+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]]


This should be more clearly made to apply to the localizable members.

marcoscaceres · 2017-05-03T07:04:25Z

index.bs

+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).


Is this bit about inherited dictionaries ok?

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?

I'm not sure. You'd have to check the bidi algorithm I'm afraid.

np, checking

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?

? 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!

@domenic, we can probably merge LocalizedValue into Localizable, or is there some reason to have it inherit from Localizable that I'm not seeing?

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 🎉.

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.

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!

annevk · 2017-05-03T07:20:37Z

index.bs

@@ -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


This needs to be plural. It's not just one.

bzbarsky · 2017-05-03T14:46:50Z

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?

annevk · 2017-05-03T14:49:14Z

Yes.

marcoscaceres · 2017-05-04T04:52:32Z

Ok, new version is up with LocalizableString added.

annevk · 2017-05-04T05:05:44Z

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.

marcoscaceres · 2017-05-04T05:19:57Z

@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.

annevk · 2017-05-04T05:36:33Z

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.

marcoscaceres · 2017-05-04T06:04:04Z

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.

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!).

Notifications set the precedent for hasn't resulted in complaints.

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:

l10n_fail.m4a.zip

Users (including me) don't need more of that in their life. My motivation is to use LocalizedStrings in the Web Payments front-end of Firefox... but yes, it would depend again on developers doing the right thing.

HTML

Does a good job with elements, because you can be quite explicit by setting dir, lang. For content attributes, like title, it's definitely not great.

and Notifications set the precedent for hasn't resulted in complaints.

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).

annevk · 2017-05-04T07:08:35Z

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.

marcoscaceres · 2017-05-04T07:19:36Z

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.

tobie · 2017-05-04T07:24:01Z

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.

marcoscaceres · 2017-05-05T02:01:24Z

@tobie, something like that would be nice and would address @domenic's concerns about distinguishing between members that use DOMStrings but are not intended to be localized.

tobie · 2017-05-09T08:40:38Z

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.

annevk · 2017-05-09T08:45:01Z

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.

domenic · 2017-05-09T08:54:00Z

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.

annevk · 2017-05-09T09:05:58Z

Their position changed since https://lists.w3.org/Archives/Public/public-web-notification/2012Jul/0039.html? Pointer appreciated.

tobie · 2017-05-09T09:06:07Z

I'd rather not use extended attributes for this.

Noted.

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.

Can't we somehow have both? E.g. have dictionary members whose LocalizableString is a DOMString take the values of the lang and dir member of the dictionary:

dictionary FooBar : Localizable {
  LocalizableString foo;
  LocalizableString bar;
};

For example:

{ lang: "fr-CH", foo: { value: "hello", lang: "en-US" }, bar: "bonjour" };

where bar takes its lang value from the top-level lang attribute and foo from foo.lang.

annevk · 2017-05-09T09:06:52Z

We can, but it's not clear to me the complexity is justified.

marcoscaceres · 2017-05-15T01:52:38Z

Their position changed since https://lists.w3.org/Archives/Public/public-web-notification/2012Jul/0039.html? Pointer appreciated.

@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)

annevk · 2017-05-15T07:52:51Z

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.

marcoscaceres · 2017-05-16T03:50:02Z

@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.

annevk · 2020-04-30T07:32:01Z

@marcoscaceres what's the status around this now?

marcoscaceres · 2020-04-30T07:39:26Z

Let's close.

WIP: add localizable dictionary

d743b7f

marcoscaceres mentioned this pull request May 2, 2017

l10n: adds Localizable dict + TextDirection enum w3c/payment-request#455

Closed

annevk reviewed May 2, 2017

View reviewed changes

Split up Localizable and TextDirection. (#1)

bf5bcb0

* 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.

annevk reviewed May 2, 2017

View reviewed changes

fix some wording as suggested by Annevk

381de47

marcoscaceres commented May 3, 2017

View reviewed changes

Make it clear that it's one or more paragraphs

97f6d52

annevk reviewed May 3, 2017

View reviewed changes

members should be plural

bc58e24

Adds LocalizableString enum

e78d5f5

domenic mentioned this pull request May 18, 2017

Serialization of natural language in data formats such as JSON [I18N] w3ctag/design-reviews#178

Closed

3 tasks

tobie mentioned this pull request Jul 28, 2017

TAG discussion pointer w3c/string-meta#4

Open

annevk closed this Apr 30, 2020

marcoscaceres deleted the localizable branch April 30, 2020 08:11

marcoscaceres mentioned this pull request Apr 13, 2021

Localizable should be defined in WebIDL w3c/string-meta#54

Open

marcoscaceres mentioned this pull request May 13, 2021

Export 'the directionality' for Element whatwg/html#6676

Closed

WIP: add localizable dictionary #358

WIP: add localizable dictionary #358

Conversation

marcoscaceres commented May 2, 2017 • edited by pr-preview bot Loading

marcoscaceres commented May 2, 2017

Choose a reason for hiding this comment

tobie May 2, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobie May 2, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobie May 2, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobie commented May 2, 2017 • edited Loading

annevk commented May 2, 2017

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bzbarsky commented May 3, 2017

annevk commented May 3, 2017

marcoscaceres commented May 4, 2017

annevk commented May 4, 2017

marcoscaceres commented May 4, 2017

annevk commented May 4, 2017

marcoscaceres commented May 4, 2017

annevk commented May 4, 2017

marcoscaceres commented May 4, 2017

tobie commented May 4, 2017 • edited Loading

marcoscaceres commented May 5, 2017

tobie commented May 9, 2017 • edited Loading

annevk commented May 9, 2017

domenic commented May 9, 2017

annevk commented May 9, 2017

tobie commented May 9, 2017

annevk commented May 9, 2017

marcoscaceres commented May 15, 2017

annevk commented May 15, 2017

marcoscaceres commented May 16, 2017

annevk commented Apr 30, 2020

marcoscaceres commented Apr 30, 2020

marcoscaceres commented May 2, 2017 •

edited by pr-preview bot

Loading

tobie May 2, 2017 •

edited

Loading

tobie May 2, 2017 •

edited

Loading

tobie May 2, 2017 •

edited

Loading

tobie commented May 2, 2017 •

edited

Loading

tobie commented May 4, 2017 •

edited

Loading

tobie commented May 9, 2017 •

edited

Loading