Available languages for objects in 3.8

Author Message

Marc Boon

Sunday 07 May 2006 11:58:11 pm

From the specs:
http://ez.no/community/developer/specs/improved_multi_language_in_ez_publish_rev_2

Available languages

Problem: There is currently no record of what languages are available on an object, unless one accesses the attributes.

To make it easier to figure out which languages are available on an object a new field is added which stores the languages which were last published.

Question is:
How is this new field accessed?

Kristof Coomans

Monday 08 May 2006 12:22:06 am

Hi Marc

What exactly are you trying to do?

You can get a list of languages (an array with instances of eZContentLanguage) of a specific object with it's attribute "languages".

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Marc Boon

Monday 08 May 2006 12:55:42 am

Good to know. Is this new for 3.8?
This attribute is not mentioned in the documentation for 3.7:
http://ez.no/doc/ez_publish/technical_manual/3_7/reference/objects/ezcontentobject

But then I still need to loop through this array of contentlanguage objects to find out if it contains the language I'm interested in.

I would like to do:

{if $node.object.languages|contains('deu')}
  {* provide link to german version of this page *}
{/if}

HEY! this was my 100th post!
:)

Kristof Coomans

Monday 08 May 2006 1:15:15 am

Yes, as far as I know it's new since 3.8.

You get a hash back (it's not just an array as I thought before) with the locale codes as keys, so you can do something like this:

{if is_set($node.object.languages.eng-GB)}
{def $lang=$node.object.languages.eng-GB}
<a href={concat($node.url_alias, '/(language)/', $lang.locale)|ezurl}>{$lang.locale_object.language_name|wash}</a>
{undef $lang}
{/if}

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Marc Boon

Monday 08 May 2006 4:32:59 am

Thanks, will try this.
I never knew of the /(language)/locale parameter. Is this also new, or just never documented?

Marc Boon

Monday 08 May 2006 5:43:18 am

Using /(language)/locale doesn't work, because it clashes with the site access.
In my multilingual site, I use site access by url (urls start with either /eng/, /deu/, etc), and the site access has to change when switching to another language, otherwise the i18n operator doesn't translate the static template text.

I use the languages attribute of the object to find out which translations are available, and then use a string replacement (using the str_replace operator from contributions) on the node url to switch to the other site access (I only use 'nice' urls).

I wonder if there is a more elegant way to switch to another site access.

Kristof Coomans

Monday 08 May 2006 6:03:38 am

You can have an extra INI setting array with locales as key and the url for the localised site access as values.

Sample from the wiki site design I've been working on:

{def $translations=$object.languages
     $translations_count=$translations|count
     $otherLanguages=array()
     $localSiteURLList=ezini('RegionalSettings','SiteURLList','wiki.ini')}

{foreach $translations as $translation}
    {if $translation.locale|ne($object.current_language)}
        {set $otherLanguages=$otherLanguages|append($translation)}
    {/if}
{/foreach}

{if $otherLanguages|count|gt(0)}
<div class="menubox">
    <div class="menubox-title">{'Other languages'|i18n('design/wiki/pagelayout')}</div>
     <div class="menubox-content">
        <ul class="languages">
        {foreach $otherLanguages as $translation}
        {def $localSiteURL=concat($object.main_node.url_alias, '/(language)/', $translation.locale )|ezurl('no')}
        {if is_set($localSiteURLList[$translation.locale])}
        {set $localSiteURL=concat( $localSiteURLList[$translation.locale],$object.main_node.url_alias)}
        {/if}
        <li>
        {* Language name. *}
        <img src="{$translation.locale|flag_icon}" alt="{$translation.locale}" />&nbsp;
        <a href="{$localSiteURL}" title="{'View translation.'|i18n( 'design/wiki/pagelayout' )}">{$translation.locale_object.language_name|wash}</a>
        </li>
        {undef $localSiteURL}
        {/foreach}
        </ul>
        </div>
</div>
{/if}
{undef $translations $translations_count $otherLanguages $localSiteURLList}

From wiki.ini:

[RegionalSettings]
SiteURLList[eng-GB]=http://example.com/en/
SiteURLList[dut-NL]=http://example.com/nl/

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Marc Boon

Monday 08 May 2006 6:34:46 am

That's a nice solution, keeping the site access urls in a ini file. But honestly, shouldn't eZ publish be able to find out without having to resort to custom ini settings? The site access urls are already defined in site.ini, after all.

A limitation of your solution is that view parameters are not kept in url_alias, so you can't switch to the exact same view in the other language. That's why I use the string replacement on $site.uri.original_uri, and not on $node.url_alias

Kristof Coomans

Monday 08 May 2006 7:22:59 am

Thanks for mentioning the issue with the view parameters. I think it won't be that hard to get them in the link too (the google navigator does it).

I agree with you that this should be handled by an internal system if possible, but I don't immediately see any nice way it could be done.

A site could have different site accesses with the same locale, but just another view on the data (admin - user site, but I can think of other examples too, like a custom interface meant for editors). How would you distinguish between those to get the right localised site?

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Paul Forsyth

Monday 08 May 2006 9:38:31 am

There was a discussion about this on the mailing list a few months back:

http://lists.ez.no/pipermail/sdk-public/2006-February/001901.html

Part of the thread touches on this.

Xavier Dutoit

Monday 08 May 2006 10:24:33 am

Hi all,

Got an issue with the i18n operator. So far, it takes the locale as defined by the siteaccess. However and as mentionned, it can be quite problematic, for instance using /(language)/xxx

In that case, I would like to set the locale to the xxx locale set by the url.

Any idea how to do that ?

X+

http://www.sydesy.com

liu spider

Monday 08 May 2006 2:19:11 pm

I wanted to setup an ez site with multi-language support. I do not want separate siteaccess for different languages, as besides two ini settings are different, all the remaining are the same

I came up with a similar require as Xavier Dutoit asked, however, I found out, there is no official hooks for something like this, I had to modify index.php to add my code, rather than in an extension

This kind of setup for multi-language support is common, and eZ should provide an official way to specify the language the UI should use (the locale setting in regionsetting)

I do not think /(language)/lang is a good idea, as it should appear in all urls in order to use this language, so I think a better way is to add language into the ez url:

samples:
url based siteaccess:
/siteaccess/eng-GB/module/function

or virtual host based install:
/eng-GB/module/function

for backward compatibility, if no language is specified in the url, then just use the default one (as the case in url based siteaccess, when missing siteaccess, it just uses the default one)

what do you guys think?

http://liucougar.scim-im.org
SCIM Input Method Platform
http://scim.sf.net
SJSD Online Editor
http://sf.net/projects/sjsd

liu spider

Monday 08 May 2006 2:22:05 pm

to Xavier Dutoit:
BTW: in case you want to know, the trick I found to overwrite the default language is to do something like this in index.php:

$GLOBALS["eZLocaleStringDefault"]='chi-CN';

in order for this to work, you have to insert that line into some where before this line:
$check = eZHandlePreChecks( $siteBasics, $uri );

in index.php, otherwise your UI will not be translated to the language you specified

no public API is available, so this is the only way I can come up with atm

this is why I think eZ should have the language in the url

http://liucougar.scim-im.org
SCIM Input Method Platform
http://scim.sf.net
SJSD Online Editor
http://sf.net/projects/sjsd

Xavier Dutoit

Tuesday 09 May 2006 1:09:27 am

@liu,

So you parse the url and see if there is a (language)/xxx and if this is the case you set $GLOBALS["eZLocaleStringDefault"]='xxx'; ?

Does it also work to fetch content and are they fetched on the proper xxx language ?

Last but not the least: have you been able to fetch this value on the template using a template operator (I fell I'm going to need it, for instance as cache key or to fetch different content based on the language...).

Xavier

http://www.sydesy.com

Marc Boon

Tuesday 09 May 2006 3:00:28 am

Liu wrote:
"I do not want separate siteaccess for different languages, as besides two ini settings are different, all the remaining are the same"

You can put all common settings in an extension, and in each siteaccess per language you only specify the regional settings (locale etc) and the extension that is common for all languages.

Like this:
/settings/siteaccess/english/site.ini.append.php:

[RegionalSettings]
Locale=eng-GB
etc.

[ExtensionSettings]
ActiveAccessExtensions[]=my_site

/settings/siteaccess/chinese/site.ini.append.php:

[RegionalSettings]
Locale=chi-CN
etc.

[ExtensionSettings]
ActiveAccessExtensions[]=my_site

Then in /extension/my_site/settings you put all the ini.append.php files which are common to all language versions of your site.

You don't have to mess with kernel files at all!

liu spider

Tuesday 09 May 2006 7:11:29 am

to Xavier Dutoit:
content language can be changed using:
eZContentLanguage::setPrioritizedLanguages

to Marc Boon:
sounds like a better idea, will give it a try. thanks

http://liucougar.scim-im.org
SCIM Input Method Platform
http://scim.sf.net
SJSD Online Editor
http://sf.net/projects/sjsd

Fabio Carissimi

Tuesday 09 May 2006 7:55:47 am

I tried $GLOBALS["eZLocaleStringDefault"]='xxx'; in index.php but it does not work.

I wanted to use this method to change my current language.
Doing so, I want the content to be in the selected language and also the
other links of my page (related links, menu, etc ...) to be proposed in
the selected language if available.

I understand that I can do it with something like that :

$languages = array( 'nor-NO', 'eng-GB' );
eZContentLanguage::setPrioritizedLanguages( $languages );

this is sample code from ezpublish-3.8.0/doc/features/3.8/multi-language_features.txt

but when I try it, I have the following fatal error :
Undefined class name ezcontentlanguage

Can somebody help me to use this fonction setPrioritizedLanguages to set the prioritized languages ?

Many thanks

liu spider

Wednesday 10 May 2006 8:57:27 am

to Marc Boon:
Yes, the approach you mentioned functions as expected

now I am one step away from what I want:
I want more than one site using the same eZ installation:

for example, for these two domains (usingf separate database)
www.a.com
www.b.com
both of which in turn have several siteaccess (for different languages)

I can not find out how to fit this into existing eZ access matching mechanism without modifying the index.php

http://liucougar.scim-im.org
SCIM Input Method Platform
http://scim.sf.net
SJSD Online Editor
http://sf.net/projects/sjsd

Marc Boon

Thursday 11 May 2006 2:34:28 am

I had exactly the same question when I started with eZ Publish in January. This was my first post on the forum:
http://ez.no/community/forum/setup_design/how_to_create_multiple_multilingual_sites_in_one_install

The question was never answered. I also posted it here:
http://ez.no/community/forum/install_configuration/how_to_create_multiple_multilingual_sites_in_one_install
Also not a single reply.

I resolved it by using different names for the same language in the different sites, like eng/english, deu/deutsch etc. and use uri-based site access. Not ideal, but it works. You can prevent access from one site to another by using .htaccess files in each site access' root directory.

I hoped that 3.8 with it's 'improved multilanguage support' would have improved on this, but I don't think it did.

Maybe we should continue this discussion in the above thread, because it's kind of off-topic.

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.