We don't check error of unum_open, so we should check it. Because
unum_setAttribute doesn't have UErrorCode parameter.
MozReview-Commit-ID: 3j7jeiKbdG
--HG--
extra : rebase_source : 61d0daf8f14f1a36623967d9d63648a8a88e25ae
On Windows 7, there is yy/mm/dd'('ddd')' as short date format of Japanese.
When selecting this, ddd isn't converted to day of the week correctly.
FindInReadable will update start position iterator even if not found. So when
using FindInReadable again, we have to reset start position iterator.
MozReview-Commit-ID: AoS1Txq3Twc
--HG--
extra : rebase_source : 2f02189d0288e833debb2d4ca47efbca632924e5
Add BrowserLocaleManager.refreshLocales, a native function which calls OSPreferences::Refresh, and BrowserLocaleManager.getLocale, which returns the current locale string. Use these in place of observing modification of the intl.locale.os pref.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: KXJM13VRTB7
--HG--
extra : rebase_source : 3e50b1b3f23248d668d15310554559c39ff792f7
extra : source : 74f5e05877d50a79ec1e5330c227d2ce576a2d90
Add additional logic to our language negotation to do apply likelySubtags when a direct match is not available.
Currently, if the user specifies the locale with region, and we do not have a direct for that region, we pick all locales for the same language and other regions in no order.
The example of where it returns suboptimal results:
1) Requested locale "en-CA"
2) Available locales ["en-ZA", "en-GB", "en-US"]
3) Negotiated locales ["en-ZA", "en-GB", "en-US"]
This would not happen, if the user requested a generic "de", "en" etc.:
1) Requested locale "en"
2) Available locales ["en-ZA", "en-GB", "en-US"]
3) Negotiated locales ["en-US", "en-ZA", "en-GB"]
because after not finding a direct match, we would use likelySubtags to extend "en" to "en-Latn-US" and then find the priority match in "en-US".
This patch extends this logic to "en-US" or "de-LU" by adding a step which strips the region tag and then applies likelySubtag on the result.
This means that in absence of direct match the following fallbacks would happen:
"de-LU" -> "de-DE"
"es-CL" -> "es-ES"
"en-CA" -> "en-US"
This does not affect languages that use multiple scripts, so ar, sr and zh are not affected.
MozReview-Commit-ID: BR1WrgXSf6a
--HG--
extra : rebase_source : abc205c4f993680ab0cd0c8b8c016543d5462d01
By the time the LocaleService destructor is called, by definition sInstance
has been cleared and its preference observers have been removed, since both
are strong references. In practice, this doesn't seem to cause trouble, but it
does lead to worrying warnings at shutdown in debug builds, which are annoying
red herrings when debugging other issues.
MozReview-Commit-ID: IalOigr2GWN
--HG--
extra : rebase_source : f86a8e81b91c639dedaca85e5bc3b53d54e01645
extra : histedit_source : 643b76de0d29ca4890ac4dd4175259989a63688e
Until Firefox 54, font fallback uses user locale. Example, OS is Windows 10 JA with JA UI, Firefox uses JA font for fallback even if Firefox is US version.
But since we changed some locale code on Firefox 55 development cycle, there were some regressions such as bug 1346674. So we changed fallback locale to system locale (instead of Firefox UX locale) for font selection by bug 1348259.
It isn't good for old compatibility, so we should use user locale for font fallback like Firefox 54. Now we can get user locale by OSPreferences::GetRegionalPrefsLocales, use it for font fallback
MozReview-Commit-ID: 7qwDDeU1ZPt
--HG--
extra : rebase_source : 3a307dd239bea516e117961a944b714bc43a993c
This should be the only callee affected, given
gfxPlatformFontList::GetFontPrefLangFor already uses case-insensitive string
comparison.
This makes it also consistent with the rest of the functions in the file, which
lowercase their inputs as well.
MozReview-Commit-ID: 4fNUBdpayHL
--HG--
extra : rebase_source : d669f5da2a1ed06f6348fc6b86eb379b514ddcf3
Original issue is that Microsoft Dynamics CRM uses invalid lang attribute in <xsl:sort>.
<xsl:sort order="descending"
select="@displayname[$sortColumnName='displayname'] |
@name[$sortColumnName='name'] |
exslt:node-set($FriendlyTypeNames)/types/type[@xmlName=current()/@datatype and $sortColumnName='datatype']"
lang="$languageName"/>
Our XSLT implementation detects "$languageName" as locale name, then use it to nsICollation.
Until Gecko 54 for Windows, even if using invalid locale name for nsICollation, it uses platform locale as fallback. But from 55, we use same implementation as macOS's to use ICU. So this issue occurs. ICU implementation doesn't use fallback locale if it is invalid.
We should use fallback locale if locale is invalid. Most code for fallback locale such as FallbackEncoding uses application locale, so use it.
MozReview-Commit-ID: EKYkZG7Hnz0
--HG--
extra : rebase_source : fec89c67317d7df041f3b237122fb7e20e32fe1b
HasRTLChars() appears in profile of attachment 8848015 after landing the patches
for bug 1391538 because the landing made text in <input> or <textarea> always
treated as non-single byte characters. Therefore, HasRTLChars() is now called
by nsTextFragment::SetTo() a lot in editors.
HasRTLChar() checks if it's in an RTL character for each character until it
becomes true. However, if character is less than the minimum RTL character,
U+0590, it works faster at least for Western languages.
MozReview-Commit-ID: 4YecxQWUcmK
--HG--
extra : rebase_source : 172be670795f0e2155d4bd5044ee37f652367734
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is only used in ways that nsCStrings can also be used
(i.e. no null checks or implicit conversions to |char*|).
In every case the patch trivially replaces the nsXPIDLCString with an
nsCString. (Also, there are a couple of unused nsXPIDLCString variables that
the patch simply removes.)
This patch introduces a new registry for localization resources to replace
ChromeRegistry. It uses asynchronous I/O and iterators to generate
permutations of possible sources of language resources for use in the new
Localization API.
In the initial form the API handles packages resources and has API for
interacting with the AddonsManager which will report language packs.
MozReview-Commit-ID: LfERDYMROh
--HG--
extra : rebase_source : 68a664c2c59a82b4dfcae66542c315a00ddae565
This patch lands the core of the new localization API:
* Parser for the Fluent syntax called "FTL"
* Resolver for the Fluent logic
* MessageContext class which is a central class for storing and operating
on Fluent messages.
MozReview-Commit-ID: E7nKGsLOCJe
--HG--
extra : rebase_source : 893178263744ef6cf6e64c135d28e10a53b61a19
This patch introduces a new registry for localization resources to replace
ChromeRegistry. It uses asynchronous I/O and iterators to generate
permutations of possible sources of language resources for use in the new
Localization API.
In the initial form the API handles packages resources and has API for
interacting with the AddonsManager which will report language packs.
MozReview-Commit-ID: LfERDYMROh
--HG--
extra : rebase_source : a6e5b790142e5afb1ce750478190e5ad87012f8d
This patch lands the core of the new localization API:
* Parser for the Fluent syntax called "FTL"
* Resolver for the Fluent logic
* MessageContext class which is a central class for storing and operating
on Fluent messages.
MozReview-Commit-ID: E7nKGsLOCJe
--HG--
extra : rebase_source : 9bb4c7b155c8b9bd8923534b69f643a6e85bb8af
Makoto Kato
Francesco Lodolo (:flod)
Jonathan Kew
Zibi Braniecki
André Bargull
Dylan Roeh
Chris Manchester
Nika Layzell
Sebastian Hengst
Masatoshi Kimura
Nick Alexander
Nicholas Nethercote
Wes Kocher
Chris Peterson
Mantaroh Yoshinaga
Phil Ringnalda
Kris Maglione
Henri Sivonen
Mats Palmgren
Emilio Cobos Álvarez
Masayuki Nakano
Simon Lindholm
Carsten "Tomcat" Book
Kirk Steuber