[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Encoding customization variable names
From: |
Gavin Smith |
Subject: |
Re: Encoding customization variable names |
Date: |
Fri, 22 Jul 2022 23:06:03 +0100 |
On Fri, Jul 22, 2022 at 10:41:26PM +0200, Patrice Dumas wrote:
> This looks good to me. I think that the locale encoding should also be
> a customization variable, but in the documentation it would be stated that
> "You should not need to explicitly set this variable." It is possible
> to pass it simply as a key (in lower case) as is done for 'values'. But
> I think that the less variables like that there is, the best it is. And
> it could even make sense for a user to override the locale encoding if
> the system is not well set up. Maybe simply LOCALE_ENCODING?
I've got the code for this mostly written, will commit tomorrow after
I do a bit more testing.
- Re: Encoding customization variable names, Gavin Smith, 2022/07/22
- Re: Encoding customization variable names, Gavin Smith, 2022/07/22
- Re: Encoding customization variable names, Patrice Dumas, 2022/07/22
- Re: Encoding customization variable names,
Gavin Smith <=
- Re: Encoding customization variable names, Eli Zaretskii, 2022/07/23
- Re: Encoding customization variable names, Patrice Dumas, 2022/07/23
- Re: Encoding customization variable names, Eli Zaretskii, 2022/07/23
- Re: Encoding customization variable names, Patrice Dumas, 2022/07/23
- Re: Encoding customization variable names, Gavin Smith, 2022/07/23
- Re: Encoding customization variable names, Eli Zaretskii, 2022/07/24