[MAGNOLIA-6890] TemplatingFunctions: Provide possibility to resolve language string to Locale object. Created: 29/Nov/16 Updated: 03/Jan/17 |
|
| Status: | Accepted |
| Project: | Magnolia |
| Component/s: | core, templating |
| Affects Version/s: | 5.4.9, 5.5 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Christian Ringele | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 2 |
| Labels: | to-verify | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Template: |
|
| Patch included: |
Yes
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Date of First Response: |
| Description |
|
For creating a language switch (for example in a navigation) one will use this TemplatingFunctions method (as also the travel demo does): [#assign localizedLinks = cmsfn.localizedLinks()!] the problem is, that the map contains the languages (Strings) as keys and not the Locale object itself. One reason is, that when Freemarker transforms the map to a hash sequence, it has trouble to use a complex object as the key (the Locale itself) when resolving by the key for an element. The problem:
${model.getLocale(lang).getDisplayName()!}
This is just not usable in a light development approach... Solution / Improvement: public Locale getLocale(String language) { // Must catch throwing exception for returning properly Null to the Freemarker script. try { return LocaleUtils.toLocale(language); } catch (Exception e) { log.warn("Unable to resolve Locale for language {}", language, e); } return null; } So one can do in a navigation script the following:
${cmsfn.getLocale(lang).getDisplayName()!}
Side Topic:
public boolean isCurrentLocale(Locale locale) {
return StringUtils.equals(aggregationStateProvider.get().getLocale().toString(), locale.toString());
}
Already existing:
public boolean isCurrentLocale(String language) {
return StringUtils.equals(aggregationStateProvider.get().getLocale().toString(), language);
}
|
| Comments |
| Comment by Christopher Zimmermann [ 19/Dec/16 ] |
|
I agree that there should be an OOTB way to get the current locale in a templatescript, including the isCurrentLocale change. |
| Comment by Jan Haderka [ 20/Dec/16 ] |
|
as a frontend developer:
I guess what it boils down is: What is the benefit of introducing Locale object for front end developers, apart from familiarity of such object for backend developers? I don't see any. All I see is extra duplication of all language related methods currently accepting String as parameter. The only real problem I read between the lines is - there is no easy way to obtain display (nice, readable) name of the current (or any) language at the moment. However to me, it remains to be determined whether solving this problem has to be done by exposing locale object or whether that can be internalized and exposed e.g. by cmsfn.getDisplayName(String someLanguage) |
| Comment by Christopher Zimmermann [ 20/Dec/16 ] |
|
I like the suggestion of just a simple method that returns the name of the language, ie cmsfn.getLocaleDisplayName(String someLanguage), as a simple alternative that probably solves the problem. |
| Comment by Christian Ringele [ 03/Jan/17 ] |
|
I think we should stop trying to foreseen, what a Front-End person might use and need out of an available Object/set of possible data. What is our gain of not providing the Locale? not having to duplicate 2 methods...? It was just a suggestion, the ticket is about the Locale object itself. Front end developers are not stupid, and reading a Javadoc of the Locale object is... come on a really easy thing to do for any developer. Fact is:
I think the Locale itself provides quite some useful methods/data for a front end developer. Just some examples: |