[MGNLUI-3616] Specify content-app available languages Created: 06/Oct/15 Updated: 15/Jan/24 |
|
| Status: | Accepted |
| Project: | Magnolia UI |
| Component/s: | content app |
| Affects Version/s: | 5.4.2 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Richard Gange | Assignee: | Dominik Maslanka |
| Resolution: | Unresolved | Votes: | 2 |
| Labels: | blocked, i18n, site_definition, support | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| 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: | |||||||||||||||||||||||||
| Epic Link: | Support | ||||||||||||||||||||||||
| Team: | |||||||||||||||||||||||||
| Description |
|
Just like you can configure site definitions on a per site (per path) basis it would be a nice improvement if you could do that same within any content app. For example, let's say I have an articles app. I use this articles app for managing articles for 2 different sites. The different sites are represented in the content app as 2 folders with the same name as the site they hold articles for. Lets say site1 has en and es configured. Now if I want my articles translated in my content app then I would have to configure the fallback definition to have all 4 languages. Then when I open the detail subapp to edit my article the drop down would have all 4 languages even though only 2 of them are valid. So then my only option is to educate the users. This might be frustrating for users because then you would need to check with site has which languages. |
| Comments |
| Comment by Mikaël Geljić [ 23/Jun/16 ] |
|
This needs to be considered with "content types" in mind; most likely we need a definition of content types / workspaces. Just food for thought really |
| Comment by Richard Gange [ 02/Aug/16 ] |
|
mgeljic That certainly makes more sense. So essentially do you envision language configuration being part of the content app's configuration? |
| Comment by Mikaël Geljić [ 02/Aug/16 ] |
|
The closest we have right to a content type definition is either the "editor" definition of a content app, or a dialog definition really. And we have additional info about where this content lives in the content-connector definition. How I personally envision this is to consolidate that as one, new, content-type definition, i.e. new registry. Then we can simplify content apps along the way. This needs to be formalized further on a concept page, I'll try to make up some time for this, as this is also targeted at 5.5 at the moment. |
| Comment by Sathyaprakash rao [ 05/Mar/18 ] |
|
Just for the record: our (at Avon Budapest) solution for this problem was quiet simple. We have extended the MultiSiteI18nAuthoringSupport.class and overrode the getAvailableLocales(Node node) method, then set to use it in /server/i18n/authoring. As a convention, our content apps workspaces has the same first level node names as the site configurations, and this new method gets the available locales from SiteManager.getSite(siteName).getI18n().getLocales() (and falls back to MultiSiteI18nAuthoringSupport locales if it did not find site-i18n locales for the given first level node name) This way, for example, nodes under "avon-hu" node in our custom workspaces, the content app users will be able to select only the languages set in "avon-hu" site config. I don't think it's the best solution, but works, and maybe you'll find it helpful. cheers, Peter Schrott (in the name of Sathya) |