Issue metadata
Sign in to add a comment
|
Web speech API lang format is not following specification (BCP 47)
Reported by
ste...@selessia.com,
Sep 5 2017
|
||||||||||||||||||||||||
Issue descriptionSteps to reproduce the problem: 1. window.speechSynthesis.getVoices()[0] 2. Check lang format. it should be en-US, it is en_US. Also consider SpeechSyntesisUtterance-lang What is the expected behavior? According to the spec, the lang should use a dash separator, not underscore. https://developer.mozilla.org/en-US/docs/Web/API/SpeechSynthesisVoice http://schneegans.de/lv/ (BCP47 validator) Chrome on Mac: window.speechSynthesis.getVoices()[0] SpeechSynthesisVoice {voiceURI: "Alex", name: "Alex", lang: "en-US", localService: true, default: true} What went wrong? You tell me :) Lang should be en-US, it is en_US. Did this work before? No Does this work in other browsers? Yes Chrome version: 60.0.3112.107 Channel: stable OS Version: 7.1.1 Flash Version:
,
Sep 5 2017
@stefan: Thanks for the report!! Could you please provide us details of your device and if possible please attach a screencast to check the issue from our end. Thanks!!
,
Sep 5 2017
Go to this proof of concept in Android Chrome and then desktop Chrome. https://plnkr.co/edit/JCw4LTqELuZ5U3KnwU7O?p=preview
,
Sep 5 2017
Nexus 9 running 7.1.1 sec patch level May 5 2017
,
Sep 5 2017
Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 5 2017
,
Sep 6 2017
stefan@..thanks for the URL/repro case.. Able to reproduce the issue on Nexus 9, 7.1.1/NMF27E using Stable 61.0.3163.81, Dev 62.0.3199.4 Sceenshot at go/chrome-androidlogs/761926 Not a regression, issue existing from M56 builds, 56.0.2924.87. Able to repro on below devices/OS also - Sony Xperia C6902 / 4.4.4/ 14.4.A.0.108, Stable 59.0.3071.125 Samsung Galaxy J7 (SM-J710F) MMB29K/ 6.0.1 using 56.0.2924.87, 61.0.3163.81
,
Sep 6 2017
This bug often arises because programmers fail to distinguish an IETF langtag from an operating system locale string. IETF langtag uses hyphens: e.g., "en-US". Unix locale strings often use underscores: e.g., "en_US". Locale strings may also carry information about the character set and sorting order. AFAIK, Unix does not have a well-known method of converting locale strings to langtags. Furthermore, Unix locale strings are supposed to be "opaque" (i.e., not standardized), so any editing of a locale string is ad hoc. A typical ad hoc edit would change underscores to hyphens and remove anything after "-u-". Windows locale strings are even more bizarre because they can be much different from IETF langtags. Java has a .toString representation of a locale object that might look like "zh_TW_#Hant-x-java" (with underscores and other cruft; equiv IETF langtag would be "zh-Hant-TW"). Java has a method .toLanguageTag that returns a well-formed IETF langtag based on the locale object. .see https://docs.oracle.com/javase/7/docs/api/java/util/Locale.html
,
Oct 12 2017
,
Sep 20
#1 is right that this is a dupe of issue 522840. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by ste...@selessia.com
, Sep 5 2017