l10n: adds Localizable dict + TextDirection enum #455

marcoscaceres · 2017-03-14T00:34:56Z

closes Add dir/lang member on dictionaries whose content is displayed in browser UI #327
PaymentShippingOption and PaymentItem inherits from WebIDL Localizable
The label members of the above are defined as localizable members

marcoscaceres · 2017-03-14T00:36:39Z

WIP, seeking feedback. It's just missing a statement about how to use the information when presenting the strings in a UI.

marcoscaceres · 2017-03-14T00:39:44Z

index.html

@@ -1108,7 +1108,7 @@
        <dfn>PaymentDetailsBase</dfn> dictionary
      </h2>
      <pre class="idl">
-        dictionary PaymentDetailsBase {
+        dictionary PaymentDetailsBase : Localizable {


I want this to apply to PaymentDetailsUpdate.error, which is why put it here.

I don't think it should go here if it only applies to PaymentDetailsUpdate. Instead you're going to have to just duplicate the two things (or use a partial dictionary PaymentDetailsUpdate).

If you put it here then PaymentDetailsInit gets it, and in particular that means passing { get dir() { throw new Error("boo"); } to places that expect a PaymentDetailsInit must throw.

marcoscaceres · 2017-03-14T00:42:22Z

index.html

-          member that will be displayed to the user. For example, this might
-          commonly be used to explain why goods cannot be shipped to the chosen
-          shipping address.
+          <a>PaymentDetailsUpdate</a> can contain a human-readable message in


I'm using "human-readable" as the key that binds together all these "localizable" members. Need to formally define "human-readable" as being potentially affected by dir/lang when present.

("human-readable" was already in use in the spec, which is why I reused it - maybe we can come up with something nicer)

domenic · 2017-03-14T03:25:42Z

Would be good to land after #451 to avoid conflicts.

Notably this does not allow serving up multiple options with different locales and allowing the browser to choose between them. I guess that is a non-goal.

It's also noteworthy that this matches NotificationOptions already, so that's good. Maybe we can consolidate this Localizable type into Web IDL or similar. /cc @annevk @beverloo @tobie. Notifications defaults lang to "" BTW to represent, I guess, no language selected. That makes sense.

Also, this standard says it represents a BCP 47 language tag, but that's not quite accurate; a developer could pass in "asdf" and there's no normative text rejecting that. You'll instead want something similar to the verbiage at https://notifications.spec.whatwg.org/#language.

marcoscaceres · 2017-03-14T04:50:24Z

Notably this does not allow serving up multiple options with different locales and allowing the browser to choose between them. I guess that is a non-goal.

Yeah. Non-goal I think.

It's also noteworthy that this matches NotificationOptions already, so that's good. Maybe we can consolidate this Localizable type into Web IDL or similar. /cc @annevk @beverloo @tobie.

I was thinking the same.... would be great to have this in Web IDL. Maybe we can craft Localizable here first, and then push it to WebIDL?

Notifications defaults lang to "" BTW to represent, I guess, no language selected. That makes sense.

Will fix.

Also, this standard says it represents a BCP 47 language tag, but that's not quite accurate; a developer could pass in "asdf" and there's no normative text rejecting that. You'll instead want something similar to the verbiage at https://notifications.spec.whatwg.org/#language.

Yeah, that's some good wording.

annevk · 2017-03-14T07:26:48Z

Uplifting to IDL seems reasonable. We already put some shared concepts and processing models there.

tobie · 2017-03-14T09:50:16Z

Yeah, seems this could go in §4 Common definitions.

ianbjacobs · 2017-03-14T15:13:47Z

@domenic wrote:

"Notably this does not allow serving up multiple options with different locales and allowing the browser to choose between them."

If I understand your comment, it is about support for multiple strings in multiple languages.
A long time back we discussed whether the API needed to support this. Our conclusion at the time was that it did not, because people could adjust content based on global directives like HTTP language negotiation.

(If you were talking about something else; sorry for the noise.)

Ian

domenic · 2017-03-14T15:20:17Z

Yeah, it makes sense. So this is mostly about allowing people to markup certain messages as having a different lang/dir than the rest of the content on the page.

zcorpan · 2017-03-15T12:03:32Z

index.html

+          <dfn>auto</dfn>
+        </dt>
+        <dd>
+          Directionality is determined by the [[!BIDI]] algorithm.


The bidi algorithm should be used for ltr and rtl as well... right?

I think we basically want to hook into http://www.unicode.org/reports/tr9/#Explicit_Directional_Isolates similarly to what CSS does in https://drafts.csswg.org/css-writing-modes-3/#unicode-bidi (for isolate or plaintext -- not sure which is more appropriate here).

https://notifications.spec.whatwg.org/#direction has the text you need for this.

Thanks, will try to draft it soon.

zcorpan · 2017-03-15T12:06:42Z

cc @w3c/i18n-reviewers

domenic · 2017-04-24T22:05:33Z

index.html

@@ -1108,7 +1108,7 @@
        <dfn>PaymentDetailsBase</dfn> dictionary
      </h2>
      <pre class="idl">
-        dictionary PaymentDetailsBase {
+        dictionary PaymentDetailsBase : Localizable {


I don't think it should go here if it only applies to PaymentDetailsUpdate. Instead you're going to have to just duplicate the two things (or use a partial dictionary PaymentDetailsUpdate).

If you put it here then PaymentDetailsInit gets it, and in particular that means passing { get dir() { throw new Error("boo"); } to places that expect a PaymentDetailsInit must throw.

domenic · 2017-04-24T22:06:38Z

index.html

+      </pre>
+      <p>
+        The text-direction values are the following, implying that the value of
+        the human-readable members is by default:


This sentence doesn't make sense to me.

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

blocked on whatwg/webidl#358

marcoscaceres · 2017-05-02T09:50:49Z

argh, that's not right. Seems I screwed up a rebase.

marcoscaceres · 2017-05-02T10:01:54Z

better...

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

Still blocked on discussions over in the WebIDL repo. Probably take another few days to resolve those.

tobie · 2017-05-04T06:54:52Z

index.html

@@ -2810,6 +2810,10 @@
        </dt>
        <dd>
          <p>
+            The <code><dfn>LocalizableString</dfn></code> <a data-cite=
+            "!WEBIDL-LS#dfn-typedef">typedef</a> is defined by [[!WEBIDL-LS]].


You can go ahead and just use [[WEBIDL]], btw.

Will fix globally! Thanks!

[[WEBIDL]] is informative reference, [[!WEBIDL]] is normative reference.

I meant WEBIDL vs WEBIDL-LS, sorry if that caused confusion. :(((

It's all good. I sent #524

marcoscaceres · 2017-08-31T06:06:19Z

Closing for now... will reopen if we want to add this in v2

marcoscaceres requested a review from domenic March 14, 2017 00:34

marcoscaceres added the proposal - needs discussion label Mar 14, 2017

marcoscaceres commented Mar 14, 2017

View reviewed changes

marcoscaceres force-pushed the l10n branch from 820818e to 00714be Compare March 14, 2017 01:05

zcorpan reviewed Mar 15, 2017

View reviewed changes

domenic requested changes Apr 24, 2017

View reviewed changes

marcoscaceres mentioned this pull request May 2, 2017

WIP: add localizable dictionary whatwg/webidl#358

Closed

marcoscaceres added Blocked and removed proposal - needs discussion labels May 2, 2017

marcoscaceres force-pushed the l10n branch from 00714be to 12893ab Compare May 2, 2017 09:48

marcoscaceres force-pushed the l10n branch from 12893ab to 709ef7e Compare May 2, 2017 10:01

marcoscaceres force-pushed the l10n branch 4 times, most recently from 5e4824f to 3ee967a Compare May 4, 2017 06:19

tobie reviewed May 4, 2017

View reviewed changes

marcoscaceres changed the title ~~l10n: adds Localizable dict + TextDirection enum (closes #327)~~ l10n: adds Localizable dict + TextDirection enum May 15, 2017

l10n: make labels localizable (closes #327)

7da7748

marcoscaceres force-pushed the l10n branch from 3ee967a to 7da7748 Compare May 16, 2017 04:12

marcoscaceres added the Priority: Postponed label Jul 18, 2017

marcoscaceres closed this Aug 31, 2017

marcoscaceres deleted the l10n branch October 12, 2018 03:27

marcoscaceres restored the l10n branch October 12, 2018 03:27

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

l10n: adds Localizable dict + TextDirection enum #455

l10n: adds Localizable dict + TextDirection enum #455

marcoscaceres commented Mar 14, 2017 •

edited by pr-preview bot

Loading

marcoscaceres commented Mar 14, 2017

marcoscaceres Mar 14, 2017

domenic Apr 24, 2017

marcoscaceres Mar 14, 2017

marcoscaceres Mar 14, 2017

domenic commented Mar 14, 2017

marcoscaceres commented Mar 14, 2017

annevk commented Mar 14, 2017

tobie commented Mar 14, 2017

ianbjacobs commented Mar 14, 2017

domenic commented Mar 14, 2017

zcorpan Mar 15, 2017

annevk Mar 15, 2017

marcoscaceres Mar 16, 2017

zcorpan commented Mar 15, 2017

domenic Apr 24, 2017

domenic Apr 24, 2017

marcoscaceres commented May 2, 2017

marcoscaceres commented May 2, 2017

marcoscaceres commented May 2, 2017

marcoscaceres commented May 4, 2017

tobie May 4, 2017

marcoscaceres May 4, 2017

zcorpan May 4, 2017

tobie May 4, 2017

marcoscaceres May 5, 2017

marcoscaceres commented Aug 31, 2017

l10n: adds Localizable dict + TextDirection enum #455

l10n: adds Localizable dict + TextDirection enum #455

Conversation

marcoscaceres commented Mar 14, 2017 • edited by pr-preview bot Loading

marcoscaceres commented Mar 14, 2017

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

domenic commented Mar 14, 2017

marcoscaceres commented Mar 14, 2017

annevk commented Mar 14, 2017

tobie commented Mar 14, 2017

ianbjacobs commented Mar 14, 2017

domenic commented Mar 14, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zcorpan commented Mar 15, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marcoscaceres commented May 2, 2017

marcoscaceres commented May 2, 2017

marcoscaceres commented May 2, 2017

marcoscaceres commented May 4, 2017

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

marcoscaceres commented Aug 31, 2017

marcoscaceres commented Mar 14, 2017 •

edited by pr-preview bot

Loading