Tcl Source Code

% package require msgcat 
1.3
% msgcat::mclocale ___foo__bar_soom
___foo__bar_soom
% msgcat::mcpreferences
foo__bar_soom foo__bar foo_ foo {} {} {}


In light of TIP 156 proposing to
give special meaning the the
catalog name {}, perhaps
[mclocale] should be stricter
about accepting only the documented
locale format?

Logged In: YES 
user_id=80530


modified patch applied to
core-8-4-branch (msgcat 1.3.2)
and HEAD (msgcat 1.4.1)

Logged In: YES 
user_id=99768

I don't see an obvious reason to object to the patch.
The results should be at least unsurprising.
Since frequently the locale handed to [mclocale] comes
from environment variables outside our control,
silently extracting what information we can
seems like the right thing - it beats having a mysterious
failure as an app is initialising.

Logged In: YES 
user_id=79902

As I said earlier, there are two ways forward and each is
correct in some situations.  We don't want to be hostage to
a user's broken environment, but nor do we want to encourage
the acceptance of any old random junk in situations where
the user of the msgcat package does have some control.

File Added - 82016: 811461.patch

Logged In: YES 
user_id=80530


Here's a patch that effectively leads
[mclocale] to collapse multi-_ sequences
to avoid the trouble cited in this report.
[mclocale] continues to accept anything,
but "interprets" multiple "_" in a row
and leading "_" as errors and "routes
around them".

With this patch in place, the example
output becomes:
   foo_bar_soom foo_bar soom {}

opinion?

Logged In: YES 
user_id=79902

There are two possibilities:
1) Complain if the format doesn't match what we expect
2) Silently try to extract what we can.

1) is better if we're explicitly setting the locale, and 2)
is better if it is happening "magically" during package load
time.

Logged In: YES 
user_id=80530

kennykb appears busy.
any comments, dkf?

Logged In: YES 
user_id=80530

again, looking for idea review here.