On Sat, Jun 30, 2012 at 12:21 AM, Doug Turner <dougt@mozilla.com> wrote: > > I prefer to just inherent the language/direction from the document that > makes the notification request. This keeps the API neat and simple. If it > becomes clear that this isn't enough and/or more systems start supporting > i18n directly in their notification API, we should reconsider. > I'm glad to see us addressing these i18n concerns. Just wanted to (once again) share my experiences implementing notifications for gmail. In the specific case of gmail, inheriting direction and language from the document is not particularly useful, because while the user may be viewing the English version of gmail, the language of a given email body or chat message that results in a notification may be in a different language (in fact, for multi-lingual users, this case is quite common). I can see how a language setting might have some limited use, although again I'm not certain how this would work for gmail which may mix strings in different languages in a single element (e.g. a notification title reading "Subject: <some non-english string>"). In practice, just having a "directionality" attribute added to the API would be insufficient for gmail, since gmail notifications need to alternate between different directionalities (gmail may be intermixing multiple strings with different directionality in the title or body of a notification as described above). Gmail currently addresses this using unicode bidi control characters in the text - is there a reason why this solution is insufficient for other use cases, allowing us to omit an explicit attribute?
Received on Tuesday, 3 July 2012 17:25:31 UTC