November Happy Hour will be moved to Thursday December 5th.
November Happy Hour will be moved to Thursday December 5th.
The properties would to put in the translation file must be String, LongString and culture specific. It cannot handle complex types. If you need to add your properties into the translate package, you have to write your own importer/exporter which implement ITranslationPackageImporter and ITranslationPackageExporter. Those require more works but you can control how the package generated and imported.
For translate nested content (ex: a block put into a page) you can add the content type in to a setting [translateOrCopyContenAreaChildrenBlockForTypes] in EPiServer.LanguageManager.config.
Hi Dac,
Okay that makes sense. Do the default implementations of ITranslationPackageImporter/Exporter rely on any internal interfaces or classes to Languages that I may need to reproduce?
I think I can solve most of this by checking the types match up to what you described without needing to resort to a custom implementation.
Thanks for your help.
Actually, the default exporter depend on classes which are in EPiServer.Enterprise.Internal for exporting content properties. But hope you can solve your problem without coding new one.
The Episerver Languages add-on would be perfect for a customer who wants to translate their site and send an XLIFF file to their translation company.
However the main problem I've seen is that all the content that gets put into the export package only seems to contain the Page name and Main body fields? Other properties are marked as culture specific but are not being picked up. This seems to be the same for all pages and blocks.
I couldn't find any instructions on how to configure or map what properties should be picked up.
Any help would be appreciated!