Notice Message Zend Translate

Permalink 2 users found helpful
I get the next message:

Could anyone explaine why? And tell me how to solve...

Notice: No translation for the language 'nl_NL' available. in /home/casper/www/www.deglazenschool.nl/www/concrete/libraries/3rdparty/Zend/Translate/Adapter.php on line 335

MissMarvels
 
Remo replied on at Permalink Reply
Remo
What did you do?
What version are you using?
Did you set the language in the config file?

A guess without having any information: I wouldn't be surprised if zend translate prints a notice for a string which hasn't been translated...

Did you check the translation trunk? Are all strings translated?
MissMarvels replied on at Permalink Reply
MissMarvels
I didn't do anything really...

It was an existing site updated to RC1 (5.4).

I've go the MO en PO's in place and set locale to nl-NL. THe strange thing is that the notice only shows in firefox 3.6 and sometimes in safari (PC).

I'm using the dutch translation, i think it''s not complete but i cant find the complete one (if there is).

***** SOLVED ******

You triggered me, downloaded the latest version. Created a new mo and everything is fine now.
DueSoft replied on at Permalink Reply
DueSoft
Hello MissMarvels, what mo file did you update? c5 or Zend (is there one for Zend?)
I'am not sure if the above the root cause. Because: In case there is no translation available, it just displayes the original message. (gettext feature)
Unfortunately, I got the same/similar issue after I upgraded to 5.4.0 (from 5.3.3.1) with this error message:

Notice: No translation for the language 'de_DE' available. in ..../concrete/libraries/3rdparty/Zend/Translate/Adapter.php on line 335
Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent ....

The strange thing: It does not happen instantly after setting 'LOCALE' to 'de_DE'
It takes some time of editing the website. Then, when the issue happens, I can get rid of it by disabling LOCALE setting in site.php. Turning it on again will show the error again (both directions instantly).
A view to the mentioned .../Zend/Translate/Adapter.php file revealed a dependency to the Zend logging activity.
So by clearing the c5 cache, the error disappears .... until sometime late (maybe the cache is full??) the error shows up again.

Is the c5 cache linked to the Zend cache?
Any ideas what can go wrong?
anytran replied on at Permalink Reply
anytran
hi DueSoft,I have a smae problem with you.

this site upgrade from 5.3.3.1 to 5.4.0

Notice: No translation for the language 'zh_CN' available. in ....../concrete/libraries/3rdparty/Zend/Translate/Adapter.php on line 335

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at ....../concrete/libraries/3rdparty/Zend/Translate/Adapter.php:335) in ....../concrete/startup/session.php on line 18
MissMarvels replied on at Permalink Reply
MissMarvels
Hello DueSoft and anytran,

Dispite of my message it is not solved with me either. I thought it was because adding a new and self compiled po files seemed to solve it. But it was temporarely. Since a view day's the messages are back again. Proberly a simulair behaviour as DueSoft mentioned.

So, still not solved.

By the way, i tested on a upgrade version (5331 -> 54), but also a clean 5.4 install. Both this behaviour..
katz515 replied on at Permalink Reply
katz515
We, Usagi Project, found out the problem.

We'll send you the patch soon.
katz515 replied on at Permalink Reply
katz515
This is one of Kino's suggestions

- Kino
http://www.concrete5.org/profile/-/2835/...



You can see the diff here...

http://usagi-project.org/redmine/repositories/diff/concrete5/5.4.0/...


I wish I have time to explain the detail, but busy with my other project now....

But anyway.. to explain really quickly... it's about concrete5 is not handling the error properly when a package does not have a language file.

You MUST include this if you set to non-English language.

Otherwise the error cause the session CORRUPT... and it will be nightmare...
anytran replied on at Permalink Reply
anytran
thinks katz515
I tried to change package.php to "if (file_exists($path . '/' . LOCALE)) {",

but the problem persists.
katz515 replied on at Permalink Reply
katz515
OK.

We wil look into it then...
alaincassis replied on at Permalink Reply
Same thing happends to me, with the 5.4.0 , when I apply translation.


If I clear cache, delete cache file, (but strangely, even I disable caching, cache file continue to be recreated)
then it is Safari run well and bugs appears on firefox .
And when I do it again, then it reverse, Safari Bugs, Firefox OK ! .
nicolas replied on at Permalink Best Answer Reply
nicolas
Here is a patch that solves this issue:

/concrete/libraries/localization.php

lines 15-21

Before
if (LOCALE != 'en_US') {
               if (is_dir(DIR_BASE . '/languages/' . LOCALE)) {
                  $translate = new Zend_Translate('gettext', DIR_BASE . '/languages/' . LOCALE);
               } else {
                  $translate = new Zend_Translate('gettext', DIR_BASE . '/languages');
               }
            }


after

if (LOCALE != 'en_US') {
               if (is_dir(DIR_BASE . '/languages/' . LOCALE)) {
                  $translate = new Zend_Translate('gettext', DIR_BASE . '/languages/' . LOCALE, LOCALE);
               } else {
                  $translate = new Zend_Translate('gettext', DIR_BASE . '/languages', LOCALE);
               }
            }


In this way, zend_translate always use LOCALE constant, and not HTTP_ACCEPT_LANGUAGES browser variable
patej replied on at Permalink Reply
patej
Thanks, seems to work great!
DueSoft replied on at Permalink Reply
DueSoft
nicolas,
looks like your tweak solves the issue on my site too.
Many Thanks
andrew replied on at Permalink Reply
andrew
Nice. Yeah we actually just included most of those same lines in the core for a quickie release in the next little while (which is already in place on our servers and should be coming out soon). Didn't even realize anything was amiss or not specified. That should fix most issues.
nicolas replied on at Permalink Reply
nicolas
I've posted a patch in bug zone, based on latest SVN version.

BTW It could be interesting to let the autodetection, but only when using 'auto' value for LOCAL constant.
anytran replied on at Permalink Reply
anytran
Thanks a lot