November Happy Hour will be moved to Thursday December 5th.

Translating error messages, labels, button text...etc

Vote:
 
What is the recommended way to handle labels, error messages etc within a multi-language site ? I can think of 4 ways to achieve this. 1) Content manage them on a page per page basis (but you may find yourself constantly entering the same text on each page e.g. 'Next', 'Prev', 'Invalid Postcode'...etc) 2) Create a hidden 'Global content' page where all these common labels and errors are content managed. The down side is that when you edit a page it is not obvious where these values come from. 3) Use Dynamic Properties. However, for a large site this page will stretch to a couple of hundred items making it very un friendly. 4) Use .Net resource files or an XML file (key / Value pairs). Downside is that normal editors will not be able to change them. What have other developers used ? Any pros and cons ?? Thanks in advance Jim
#12646
May 23, 2006 11:42
Vote:
 
Jim, have you viewed multilingual sample code and rejected the use of the EPiServer Translate functionality? From what I understand, you are referring to texts that are part of the page templates, such as messages displayed as a result of user interaction and similar... The standard approach to handle such strings in multilingual sites is to place the actual strings in the EPiServer language resource files (xml files in the Lang folder), and use calls to the EPiServer Translate functionality to indicate the specific strings you want to retrieve. In such scenarios, EPiServer will decide in which language the string will be retrieved, based on a number of factors. Such translation calls can be performed in a number of ways, based on the specific needs. There is a Translate web control, you can add a "translate" attribute to standard ASP.NET controls, and the PageBase, UserControlBase and LanguageManager classes expose a Translate(...) method for use in inline code or code-behind files. Regardless of the method used, you supply a simplified XPath expression to indicate which string you want to retrieve from the language files. If you have considered this approach and rejected it, please provide further details on your specific needs. You mentioned the lack of editability as a potential downside of using resource files, but you always have the option of providing editors with a user interface to manage (a subset) of your language strings. As you have access to the full .NET API, you can retrieve data from the files as desired. And using EPiServer ODA functionality such as plug-ins, you can easily provide the user interface as part of the EPiServer edit mode, if that is appropriate for you.
#14674
May 23, 2006 14:20
Vote:
 
Hi Roger, Yes, I like the idea of writing an editor and incorporating it into either the editor or admin pages. Is there any more information on the ODA ? Perhaps an approach which should be followed etc Regards
#14675
May 24, 2006 12:28
Vote:
 
Jim, I believe the white paper on EPiServer's ODA has not been updated and released for version 4.60, but the following document (available from the Knowledge Center library at EPiServer.com) from version 4.51 is still accurate and gives a brief overview of the ODA: http://www.episerver.com/downloads/Documents/WhitePapers/English/EPiServer%204.51/Open%20Development%20Architecture.pdf Basically, I suggest you create your own language file(s) in the lang folder with a custom XML structure for the various strings you need to handle (compare to the existing XML files in there). Then you write a user interface that uses functionality from the standard .NET API and web controls to read/write values to/from these files. This code does not really need to be very EPiServer specific - except for adding an EPiServer GuiPlugInAttribute (see the SDK and other documentation) to your class definition, marking the code as an EPiServer plug-in and making it appear in one of the available locations inside Edit or Admin modes. Another option would be to use Custom Property types (also part of the ODA features) to handle these strings, which might be more suitable if you would prefer the texts to be editable only for certain page types, as part of normal page editing. (Though for such a solution, you could probably rely or normal content entered in the different languages, and wouldn't really have to resort to custom development.)
#14676
May 30, 2006 13:46
Vote:
 

Jim,

Have you assessed any other methods? The EPiServer-LanguageWire translation plug-in created by Inexor will automate all translation workflow processes without the need to leave the EPiServer environment - it's a one-click solution. Translations are handled by human subject-specialists. This should relieve you (or your clients) of the headaches associated with integrating translation into the EPiServer environment or managing multilingual implementations.

Alternatively you can create your own API - we can send you some DLL files for you to integrate.

Please let me know if you need more information on this recently released module. I'm happy to give you a call to discuss.

All the best,

James

#40690
Jun 15, 2010 21:06
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.