[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:
Relates
relates to MGNLUI-6858 Languages in switcher not updating on... Open
relates to PAGES-43 Hide language chooser when using mult... Closed
causality
dependency
relation
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: Nucleus

 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.
Lets say site2 has de and fr 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.
For one, I don't see site definitions driving content languages, but content declaring a set of languages, and sites consuming part (or all) of these languages.

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)

Generated at Mon Feb 12 09:08:25 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.