[
https://issues.apache.org/jira/browse/FREEMARKER-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17568633#comment-17568633
]
Dániel Dékány edited comment on FREEMARKER-208 at 7/19/22 4:26 PM:
-------------------------------------------------------------------
I think what people want is just converting for computer consumption, as
opposed for human conversion. That is, in some case you don't want any of the
culture dependent complications, and in some others you do (and in that last
case you want to use the {{Environment}} locale, not something else). It's the
same reason we have {{?c}} for formatting numbers and booleans for server-side
parsing ("c" stands for "computer audience"). So, maybe, building on that
terminology, we should add {{?c_lower_case}} and {{{}?c_upper_case{}}}.
Admittedly people will have look up what that means, but this computer VS human
audience problem is important, and I think people have to be aware of it to not
mess it up anyway. Then they must know ?c, and then the "c_" prefix is
understandable, and convenient as it's less typing.
BTW, the purest solution is using {{Locale.ROOT}} for things like this, not
{{en_US}} (or {{{}en_en{}}}).
was (Author: ddekany):
I think what people want is just converting for computer consumption, as
opposed for human conversion. That is, in some case you don't want any of
culture dependent complications, and in some others you do (and in that last
case you want to use the {{Environment}} locale, not something else). It's the
same reason we have {{?c}} for formatting numbers and booleans for server-side
parsing ("c" stands for "computer audience"). So, maybe, building on that
terminology, we should add {{?c_lower_case}} and {{{}?c_upper_case{}}}.
Admittedly people will have look up what that means, but this computer VS human
audience problem is important, and I think people has to be aware of it to not
mess it up anyway. Then they must know ?c, and then the "c_" prefix is
understandable, and the convenient (as it's less typing).
BTW, the purest solution is using {{Locale.ROOT}} for things like this, not
{{en_US}} (or {{{}en_en{}}}).
> Allow to provide a specific locale for lower_case / upper_case
> --------------------------------------------------------------
>
> Key: FREEMARKER-208
> URL: https://issues.apache.org/jira/browse/FREEMARKER-208
> Project: Apache Freemarker
> Issue Type: Improvement
> Reporter: Florian Motteau
> Priority: Minor
>
> lower_case and upper_case filters rely on toLowerCase / toUpperCase methods.
> They use the current environment locale as first and only parameter for these
> methods.
> [https://github.com/apache/freemarker/blob/201533eb7c15e3cfc55b38da37f730a3492bec0f/src/main/java/freemarker/core/BuiltInsForStringsBasic.java#L433]
> In rare cases, we might want to provide a specific/fixed locale, to avoid
> some weird problems, such as the Turkish/Azeri dotless i problem :
> {code:java}
> // lowercasing an uppercase i, using turkish locale
> System.out.println("I".toLowerCase(new Locale("tr", "TR")));{code}
> ...will output "ı" (which is a dotless "i").
> We faced this problem in OFBiz
> (https://issues.apache.org/jira/browse/OFBIZ-12660), and although we can fix
> this for our specific use case, it may be a good idea to be able to pass a
> locale (which sould defaults to the environment locale if not provided) as
> parameter for lower_case and upper_case :
> {code:java}
> myVar?lower_case("en", "EN") {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
