[MURLTRANS-21] Use AbstractI18nContentSupport getNextLocale to fallback to a similar locale/language Created: 16/Apr/21 Updated: 30/Aug/22 Resolved: 30/Aug/22 |
|
| Status: | Closed |
| Project: | URL Translation |
| Component/s: | None |
| Affects Version/s: | 6.2.3 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Jeffrey van der Heide | Assignee: | Richard Gange |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | 0d | ||
| Time Spent: | 0.25d | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Template: |
|
||||||||
| 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 |
|
Make use of similar logic as AbstractI18nContentSupport, particularly getNextLocale to fallback to a similar locale/language. Right now when using e.g. be_NL and nl_NL; Belgium Dutch doesn't fallback to Netherlands Dutch when using this module where as the default i18n behaviour does facilitate this. It'd be great if URLTransfilter and URLTranslator would use the logic found in info.magnolia.cms.i18n.AbstractI18nContentSupport#getNextContentLocale |
| Comments |
| Comment by Richard Gange [ 30/Aug/22 ] |
|
Hello Jeffrey van der Heide- Here is my assessment after looking into this ticket. I understand what you are saying about the fallback mechanism but I don't think copying the code from AbstractI18nContentSupport is the best path forward. I've tried to find some entry point which would allow me to call the existing code but it seems it's not possible due to the protection levels of the methods in AbstractI18nContentSupport. Therefore I think the best path forward is for me to to close this issue as "Won't do" and then create a follow up ticket to change the filter so that the requested Locale is retrieved through: Locale locale = i18nContentSupport.getLocale(); By doing this it would allow you to create your own implementation of I18nContentSupport which can then be configured on your site definition. By implementing your own version of I18nContentSupport you would then have access to all protected methods. The url trans filter will simply pick up the custom implementation you have created which will sort out any fallbacks of regional dialects. Hope that makes sense. Basically what I am saying is it should not be the job of the url translation module to determine which locale should be served. Let's keep a separation of duties. The translation module should only perform translation. Kind Regards |
| Comment by Richard Gange [ 30/Aug/22 ] |
|
The followup ticket is |
| Comment by Jeffrey van der Heide [ 30/Aug/22 ] |
|
Hi Richard, It's been a while since I worked on the project where this request originated from, I'd have to dive in to this again, but I wanted to reply to you asap. That is (thinking out loud here, this would need verification);
|
| Comment by Richard Gange [ 30/Aug/22 ] |
If you look at the signatures for all methods within the translator it receives locale from the caller. So I am not sure what you mean by the translator being untouched. What should be touched? The ticket was originally about using similar logic from AbstractI18nContentSupport but I don't see how it would make sense to be copying code. The translator just translates. It doesn't sort out the language. |