replacing the chrome URL with a properly formatted locale would be transparent on metrics.
I just went back and looked at the regex. It would properly handle an escaped bogus value as well without a problem, but I'd still very much like to get mindset that any time a change happens with the structure of one of these URLs, a bug gets opened with metrics to review it for potential impact. I've opened Bug 469806 to that effect.
FYI, here is the piece of the regex that deals with the locale segment:
/(?> # locale raw_string
(?> chrome://(?:.{0,108})\.properties
# Note: some Linuxes are messed up and report chrome URL instead of locale
)|(?>
( # locale code (?>[a-z]{2,3}) # language (?>-[A-Z]{2})? # region (?>-[\w]{2,8})? # dialect
)
)|(?>
[^/]*
# Failsafe to eat unacceptable values
)
)
replacing the chrome URL with a properly formatted locale would be transparent on metrics.
I just went back and looked at the regex. It would properly handle an escaped bogus value as well without a problem, but I'd still very much like to get mindset that any time a change happens with the structure of one of these URLs, a bug gets opened with metrics to review it for potential impact. I've opened Bug 469806 to that effect.
FYI, here is the piece of the regex that deals with the locale segment:
/(?> # locale raw_string
chrome: //(?:.{ 0,108}) \.properties
(?>[a- z]{2,3} ) # language
(?>-[A- Z]{2})? # region
(?>-[\ w]{2,8} )? # dialect
(?>
# Note: some Linuxes are messed up and report chrome URL instead of locale
)|(?>
( # locale code
)
)|(?>
[^/]*
# Failsafe to eat unacceptable values
)
)