I am trying to work out how EPiServer CMS 6 deals with multilingual support/translation of site text such as form component labels, error messages, etc. The sort of content you'd usually put in a resx.
I really need the individual language editors to be able to edit these from within EPiServer itself.
My thinking is along similar lines to this fairly old thread: http://world.episerver.com/Templates/Forum/Pages/thread.aspx?id=12646
All translations are held in XML files in the \lang folder in the root of the solution. All of the language files are read into one huge DOM on start up. You can access the translated content in your mark up as follows:
<%$ Resources: EPiServer, news.morenews %>
<language name="English" id="en">
There is no built in functionality to edit the XML files. However someone has developed a module for EPiServer 5 that allows editors to edit these XML files:
This shouldn't be too tricky to convert to EPiServer 6.
Haven't tried it but one way might be to move the langugage xml files from the origian folder to another folder outside of the project structure. Create a VPP folder pointing to that new folder and display it in the filemanager and add user rights to it.
If it works certain trusted editors could go right in and edit the xml files.
Be careful if you let editors do changes in the xml file. Small mistakes like a missing < or >, or a < inside the text will affect the site and editors will panic. Like David said, take a look at the ManageLanguages tool on EPiCode, it will help you going.
I agree, we won't be letting editors change xml files directly.
One solution I have pondered is to put the values into a hidden page and use the API to request the values from within the web controls that need them.
Can anyone see any issues with that?
Depends on how you do it. If you are planning to have one property for each text label, then you could end up with lots of properties. If you plan to have the xml in a property, then you have the same problem as if you change directly in the xml. I guess a plugin which update the xml file is the best way. Then you can control the input.
One property for each text label is what I had in mind.
I would divide them up in a similar way to how I would with resx files, i.e. by site page or site section + one for common terms. There will be a lot of labels on a page but then there will always be a lot of labels, won't there?