By specification in RFC 3066, locale names can only contain ASCII characters (in fact only a subset of ASCII), so representing them with an nsString is unnecessary.
nsACString, please, as long as you're doing this... ;) nsAFlatCString if absolutely necessary.
Yes, of course, nsACString for the interfaces and nsCString for the member data. That's what I meant ;-)
Just make sure this is compliant with BCP 47.
OS: Windows 2000 → All
Hardware: x86 → All
Yes it is. As far as I remember, it is part of the stability policy for BCP 47 that the character repertoire for language subtags will never be extended beyond US-ASCII, but I can't find a reference for this right now. At any rate, it is still the case in the current version.
The new LocaleService uses nsCString everywhere. I think this bug is fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.