W3C home > Mailing lists > Public > public-i18n-core@w3.org > April to June 2016

RE: Reviewing Social Web Specs

From: Phillips, Addison <addison@lab126.com>
Date: Sat, 25 Jun 2016 00:13:36 +0000
To: Sandro Hawke <sandro@w3.org>, "Richard Ishida, Staff Contact, i18n WG" <ishida@w3.org>
CC: "public-socialweb@w3.org" <public-socialweb@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Message-ID: <f29d8d0d9814468fbdeec237a2121406@EX13D08UWB002.ant.amazon.com>
Thanks Sandro.

But they're not stable, then.    I guess in theory we could try to notice, for each of our many specs, when we're down to issues that somehow don't bear on i18n, and then ask for i18n review, then notice when we're down to issues that somehow don't bear on a11y and then ask for a11y review, and so on with each kind of horizontal review for each spec...      I've been through this a dozen times in as many years, and I've still no idea how to do it, other than wait until all the issues are closed.  Perhaps I'm a slow learner.

That’s true: they’re not stable. But often the interesting I18N discussions are actually the best time to involve the I18N community. What makes me nervous is approaching a WG whose spec is in CR and going “oh, you didn’t think about tagging all of X with a language” or “your requirement doesn’t allow international text” or worst of all “you’re missing a feature”. WGs and implementers are not happy to have to go back to the drawing board: there is disincentive to getting to the right solution.

But it’s also true that when a spec is unstable, the comments are more distracting and less targeted and you’re busy trying to get consensus on Things That Matter (not that I18N doesn’t matter, but…)

As a WG, we’ve been trying to make the process a little more self-service. For example, we’ve started to harvest our comments and build a “best practices” document [1] to work as a kind of mini checklist. If your spec already bears our considerations in mind, then presumably we’ll only have to look at the truly novel stuff.

Ultimately, if we have six or so months, as here, we aren’t going to be rushed and do a haphazard job for you. And presumably, if we do the review in an efficient way, a lot of that time can be used in responding to our comments.

Ultimately, I’ve been doing this dozens of times a year for many years and *I* don’t think there is a panacea. I don’t think you (or I) are a slow learner. Instead I think that “just right” varies by working group and spec. And my main concern is: that our WG have enough time to do a good job for you, but not bog you down in an ocean of pointless process.

Kind regards,

Addison

[1] https://www.w3.org/TR/international-specs/


From: Sandro Hawke [mailto:sandro@w3.org]
Sent: Friday, June 24, 2016 2:37 PM
To: Phillips, Addison <addison@lab126.com>; Richard Ishida, Staff Contact, i18n WG <ishida@w3.org>
Cc: public-socialweb@w3.org; public-i18n-core@w3.org
Subject: Re: Reviewing Social Web Specs

On 06/24/2016 05:00 PM, Phillips, Addison wrote:

Hello Sandro,

Thank you for this note. I’ll be updating our review radar [1] shortly with this information.


Thanks, Addison


Do you have specific schedules or deadlines for any of these documents that we should be mindful of?

Our only hard deadline is the group will be shutting down at the end of the year.   I have fantasies of PR at the end of the summer.  So, obviously, the sooner the better, if we're to have a chance to do anything about it.


I suspect that we will want to review all of these. I must point out that reviewing a document that is already in CR or with very short time before CR is not ideal. Please consider requesting reviews closer to FPWD in the future.


But they're not stable, then.    I guess in theory we could try to notice, for each of our many specs, when we're down to issues that somehow don't bear on i18n, and then ask for i18n review, then notice when we're down to issues that somehow don't bear on a11y and then ask for a11y review, and so on with each kind of horizontal review for each spec...      I've been through this a dozen times in as many years, and I've still no idea how to do it, other than wait until all the issues are closed.  Perhaps I'm a slow learner.

MEANWHILE, that reminds me, we did notice one i18n issue with AS2, which I wrote to Richard about on May 10.  In retrospect, I should have included a larger list of recipients.   I wrote:



The Social Web WG expects to have 2-5 specs going to CR in the next two months.

One of them has an I18N issue we noticed.   The others, none yet.

The issue we notice is in Activity Steams.  This is basically a syndication format/vocabulary, for people to publish what they've been doing online.   Liking things, checking in at locations, unfriending people, etc.  It includes a standard vocabulary for common things, but anticipates lots of extensions.

It uses a constrained subset of JSON-LD as its syntax.   So that limits how it can encode lang information.  And within the JSON-LD limitations, we've chosen some more limitations.   Specifically, we've allowed exactly one way to provide lang tags.    It looks like this:

No language tag:

{ ...
  "content": "A <i>simple</i> note"
}

With language tags:

{...
   "contentMap": {
      "en": "A <i>simple</i> note",
      "sp": "Una <i>simple</i> nota"
   }
}

This should work, but it does not allow any kind of defaults.  Any property that doesn't use a lang map has no language information.  Unfortunately we're unable to find any reasonable way to allow defaults.

See discussion at https://www.w3.org/wiki/Socialwg/2015-12-02-minutes#Issue_251


Hoping that helps,

     -- Sandro


Best regards (for I18N),

Addison

Addison Phillips
Principal SDE, I18N Architect (Amazon)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.



From: Sandro Hawke [mailto:sandro@w3.org]
Sent: Friday, June 24, 2016 12:46 PM
To: Phillips, Addison <addison@lab126.com><mailto:addison@lab126.com>; Richard Ishida, Staff Contact, i18n WG <ishida@w3.org><mailto:ishida@w3.org>
Cc: public-socialweb@w3.org<mailto:public-socialweb@w3.org>
Subject: Reviewing Social Web Specs

I'm writing on behalf of the Social Web WG.  Some of our specs are now stable, and if we would value a review from your group at your earliest convenience.  While our primary use cases are often framed in terms of social media and blogging, the technologies may be broadly applicable.

So far we have three specs in or near CR:
* Webmention lets you tell a website you're linking to it.  This supports ad hoc federation of sites

https://www.w3.org/TR/webmention/


* Activity Streams (2.0) is a standard (and extensible) way to share a stream of what people do online (eg, "liking", posting a photo, etc)

https://www.w3.org/TR/activitystreams-core/

https://www.w3.org/TR/activitystreams-vocabulary/


* Micropub provides a standard Web API to create and control posts on your own website

https://www.w3.org/TR/micropub/


Additionally:
* Social Web Protocols: provides an overview, including an explanation for how the parts fit (and sometimes do not fit) together.  This document does not currently have any normative content.

https://www.w3.org/TR/social-web-protocols/


There are other documents not yet ready for horizontal review.  You'll see them linked from Social Web Protocols, and we'll send another email when they're in or near CR.

Note that the group is producing multiple stacks which are not entirely compatible, reflecting the fragmentation in this space. Basically, we decided having multiple competing specs, while not an ideal situation, would still be a step forward.

If you think your group will be doing a review, please reply-all and let us know your timeframe.  We'd very much appreciate the actual review comments being raised as issues on the repo for each particular spec (linked in the title section), and then a high-level email or summary issue stating when the review is complete.

Please feel free to share this call-for-review with anyone likely to be interested.

Thank you!

   -- Sandro Hawke, Staff Contact, W3C Social Web Working Group

Received on Saturday, 25 June 2016 00:14:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:02:12 UTC