-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: extend locale api to better reflect posix #2
Comments
Case 2 may look somehow like that: 375gnu/locale@master...test |
I'm sorry but I don't understand yet. Is the following OK?
|
On 9/16/13, Kouhei Sutou [email protected] wrote:
Yes, but only in their simplest forms. Real situation requires a bit |
Thanks for confirming it. But I'm still confused... Do you know a reference for the desired (expected) locale related behavior? locale(7)? I want the specification about locale like the XML specification from W3C for XML. Does http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690572 show the behavior expected by the specification? Or does it just show a behavior by the bug reporter? If I understand ideal behavior, I can fix the current behavior. |
On 9/17/13, Kouhei Sutou [email protected] wrote:
POSIX:
It is behavior expected by the specification. |
Thanks! |
I've pushed fix of the problem. Could you try it? |
On 9/19/13, Kouhei Sutou [email protected] wrote:
Good: Bad:
Please see my branch |
For bad case, why is What use case do you assume? |
I forgot to mention... |
On 9/19/13, Kouhei Sutou [email protected] wrote:
May be I (and not only I;)) have misunderstanding in ruby-locale API. Then, if in the most cases the correct way of using it is just |
On 9/19/13, Hleb Valoshka [email protected] wrote:
As an example, sup-mail uses Locale.current.charset to guest current |
Becauese existing library such as sub-mail uses the API. GitHub: fix #2 Debian Bug: #690572 Reported by Stefano Zacchiroli. Thanks!!! Reported by Hleb Valoshka. Thanks!!!
Oh... |
On 9/20/13, Kouhei Sutou [email protected] wrote:
I've tried. It works as expected. Thanks! |
Thanks for confirming it! |
Ah, sorry. |
It looks for me that current locale tries to be the GCD for all supported platforms, so it behaves like the simplest platform (CGI) behaves. But other platforms may have richer API, i.e. in case of CGI we have only one value for all locale categories, but in POSIX world we may have different values for different categories like LC_MESSAGES, LC_CTYPE, etc.
I didn't think of this when I proposed you this pull request (mutoh#5), especially commit mutoh@0ef254f, which fixes issues with encoding handling (LC_CTYPE), but breaks handling of LC_MESSAGES (for example, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690572).
So currently I see three possibilities:
The case 2 may be enough for the short term perspective but for long term case 3 looks better but it may require to refactor/rearchitect the whole gem.
The text was updated successfully, but these errors were encountered: