ExpressionEngine® Answers is a question and answer site for administrators, end users, developers and designers for ExpressionEngine® CMS. It only takes a minute to sign up.
Sign up to join this community
I'm looking to build upon a existing Structure built site and integrate another language. It doesn't necessarily need to be built upon using Structure, but as it's already using it and it works ok, then that makes sense.
Preferably i'd have one entry screen with an override if the existing language was entered show that body field, if not show default body. My preference for this data entry design is for client UX.
What the best way these days?
Thanks!
Have a look at transcribe. i am currently using it with structure and am pretty satisfied with it. The way you are proposing to do this will probably end up confusing visitors, as they will be seeing 2 languages mixed. With transcribe you will be creating different entries, and content of the site does not have to be equal. Each language will have it's own structure tree. If a user clicks on the language switch on a page that has no equivalent in the second language, it will show the homepage of that language version.
I don't use Structure that much so here is the process and add-ons I use to develop multilingual sites in EE in case someone is looking for an alternative:
Language Framework:
I usually use Biber Multi Language Support for this although I will probably be trying Transcribe on my next project. In the case of Biber it will allow you to define your languages and appends the languages' two character ISO code to your URL, Example: "http://example.com/es/". The language code is then also available as an early parsed variable {language_code} which you can use in your entries tags. Biber also includes the option to include static content variables for bits of text that you would not put into a channel (more on that below).
Channel Content:
I first define what channel content will be "mirrored" (content will be translated 1-to-1 in all languages) and which is not. From here I begin to plan out channels and field types.
If I know the content will be mirrored, I will create one channel for it and assign a field group to it that has separate text fields for each language. To avoid confusion for the content editor I usually group these fields in a tab for each language in the edit form, separating them from any non-language specific fields in that channel as well. The naming convention for fields I use would be, as an example: "product_summary_xx" with the "xx" part being the two letter ISO language code for that language. In your template you would then call the appropriate language field in your entries tag with the name of the field and the language variable : {product_summary_{language_code}}
If the content will be different for each language, I will create a channel for each language and then assign 1 field group with the text fields necessary to all the language channels. The naming convention for the channel would then be for example: "products_xx", again with the "xx" being the language code. To call the correct language channel in the entries tag you would then use something like this: {exp:channel:entries channel='products_{language_code}' ...}
Static Content
Static content that needs to be in multiple languages (i.e.; "Send", "Your Name", "Back", etc... basically all the bits of static texts included in your templates).
Depending on the complexity, and necessary access to the content editor of this data, I will usually use a combination of the following Add-ons:
Low Variables - If the project has content that will need to be editable by the client but it does not warrant a channel all to it's self, I will usually use Low Variables to group the multilingual semi-static data here by language, again to prevent confusion. Since you can specify early parse orders on variables you can also setup date, and number formatting strings for each language as well here. Again, the naming convention for these variables would be something like "lv_home_intro_xx" and you would call the correct language in your template like so: {lv_home_intro_{language_code}}
Biber Multi Language Support - For all remaining static texts that the client does not need to be meddling with, I use Biber's functionality for static multilingual phrases and close it off for only Super Admins and any higher level Member groups that would require access to it or member groups for translators. To output in the correct language in your templates you don't need to worry about the language code here, just the Biber variable name : {bbr-mls-special_offers}
Navigation
For creating multiple language navigation schemes I have been using Navee to create separate ones for each language. The interface is pretty intuitive which is great when you need to allow your client access to it. Creating separate navigation menus will also cover you if the site requires non-mirrored content in the navigation. You then would use the {language_code} variable again to call the correct navigation menu in your template. Example: {exp:navee nav_title='main_navigation_{language_code}'}
For language switching, the Biber add-on includes tags to output a language switcher and listings of all current languages that you can iterate through if you want to create your own markup for it.
Going to toot my own horn here. Publisher supports Structure and doesn't require any funky conditionals or nonsense in your templates to get the navigation to render.
Taken directly from Structure's Docs: ( http://buildwithstructure.com/documentation/multi-language_sites/ )
The recommended method is to have your default language at the top level and make separate branches for your alternate languages like this:
You can then use the nav_sub tag and either the start_from or exclude_status parameters. When using exclude_status you can assign statuses by language to control the output.
Example nav_sub code:
{if segment_1 'es' OR segment_1 'fr'}
{!-- START FROM SEGMENT 2 IF NOT DEFAULT LANGUAGE --}
{exp:structure:nav start_from='/{segment_1}/{segment_2}'}
{if:else}
{!-- START FROM SEGMENT 1 IF DEFAULT LANGUAGE --}
{exp:structure:nav start_from='/{segment_1}'}
{/if}
This method does not require different custom fields per language as they’re all separate pages powered by the same code and quite often the same templates.
If you're already using Structure then a simple and straightforward method would be just to create new pages for each language. This might work for you. I used it on a couple of micro-sites and the client was very happy with the results.
So your Structure tree might look something like
Home - /
Products - /products
Contact Us /contact-us
Polski - /pl
Strona główna - /pl/strona-gowna
Produkty - /pl/produkty
Kontakt - /pl/kontakt
Francais - /fr
Page d'accueil - /fr/page-daccueil
Produits - /fr/produits
Contactez-nous - /fr/contactez-nous
So each language effectively has its own "root" page which has the strucuture/url title of the language abbreviation then a collection of subpages.
To prevent people hitting the root pages of each language, I made a template that contains a single tag which redirects to the first child page of that root page.
The upshot is that whilst not sophistacted, you've got a very easy to manage site that makes it possible to provide different content or even pages on a per-language basis.
You get the idea.
EDIT: And now I see that basically someone has already given this answer!
Republic Factory wrote a great article on EE Insider about how they create multi-lingual sites - I've used this method and found it very easy to set-up. Also recommend Low Variables for handling translated content not stored in entries.
