AI OnAI Off
Handling publishing of new languages
I usually use 4 options.
1. Avoid publishing the pages and just set them to ready to publish...as editor you can browse around in edit mode until you are happy and then publish the whole bunch of pages (you can also use the new project feature)
2. Publish them but hide them from user. Don't show the new language in any language dropdowns etc, use robots.txt to hide them from search engines and don't communicate the new urls to anyone before you are happy. This works better if you have functionality on your site that you really need to test with published pages...
3. Content staging. Produce your content on another site (your staging site) and either export it to the production site, use mirroring or actually switch DNS to use the site with the new language.
4. Access rights. If you have a separate tree structure, this is a good option.
I normally choose 3 with a cloned site of production and switch by DNS if I also have lots of new functionality. I use 2 if there is only some content that isn't really secret...I rarely use 1.
May 11, 2016 15:26
Thanks for your reply Daniel.
1. They use a lot of references between pages and blocks and when viewing in the Episerver edit mode changes does not seems to update when the referenced pages/blocks are just in ready for publish mode, only when published. But this seems to work when in a project, so might be a solution for them in the future.
2. Kinda what they are doing now, but not all in with the robots.txt and explicitly hiding the pages from the search. Though they felt there should be more of a "real" function for this, therefor this post.
3. Could work, but can you do the import/export function for a specific language branch? As they use the same tree structure for all languages.
4. Indeed a good option if you can use it, but unfortunately they just have one tree structure for all languages.
// Christopher
May 11, 2016 16:04
I would really recommend looking at the features Episerver have for translations. From my experience, having one page tree structure with translations are mostly more convenient than having one for each language.
When it comes to tools, a must have is the Episerver Language Manager https://nuget.episerver.com/en/OtherPages/Package/?packageId=EPiServer.Labs.LanguageManager
This helps your editors keep track of your languages compared to the basic ones in the Episerver UI.
When it comes to managing content and not publish everything, have you looked at the new Projects feature in Episerver?
There are some great articles about it and it's one of the best features added to Episerver in a long while!
Some of the articles are
http://world.episerver.com/documentation/Items/Developers-Guide/Episerver-CMS/9/projects/introduction-to-projects/
http://world.episerver.com/articles/Items/the-projects-feature/
https://www.youtube.com/watch?v=BVQFHwQwMMs
May 11, 2016 17:00
Thanks Alf for the links and information.
I will look into the Language Manager one and see if it helps the customer.
I have looked some at the Projects feature, though the customer is running an older version where the projects mode is not yet available.
But we are planning to upgrade the site as soon they are done with their current project, so it might the solution to use the projects mode.
But a problem with the projects mode that it depends on that the editors work with it correctly. The customer have atleast one editor per language and the knowledage of each editor is a wide range of "do as they are told" and "creating wierd problems".
// Christopher
May 11, 2016 19:32
Hey everyone,
A customer I am working with is having problems with how they should work with languages in Episerver.
They work with over 15 languages with editors for each language and it is set up so each language has a group, like EN_Editors or SV_Editors.
These groups are specified to give the editors editor access to the specified language.
The WebEditor group then gives them the create/edit/publish access.
Now to the problem.
They are both working on and planning to add more languages, but when they are working with the content in a new language they don't want it to be publicly visible.
The idea is that the editors should be able to view the site while they are working on it to view how it appears for a user, and when they feel that they are done they could just "active" the language branch for visitors and it becomes public.
This could be solved by having access rights per page and per language and set so only editors have access while they are working on it, but this does not exist and we don't want to modify Episerver to much.
Do any of you out there have a similar problem with a customer and how did they solve this?
Do Episerver have any view on this problem and how to solve it? Like any best practices?
// Christopher