Issue Type: Improvement Created: 2008-04-08T10:49:07.000+0000 Last Updated: 2008-09-02T10:39:31.000+0000 Status: Resolved Fix version(s): - 1.6.0 (02/Sep/08)
Reporter: Thomas Weidner (thomas) Assignee: Thomas Weidner (thomas) Tags: - Zend_Translate
Related issues: Attachments: - Zend_Translate_Adapter.diff
Investigate possible problem with filename search.
From Rob L. UPDATE:
After a message from Robert Castley (thanks), I tried directory scan instead of filename scan. It seemed to work. Here is an example of what works and what doesn't work for me:
WORKS: ($dir contains folders zh_CN/ zh_TW/ en/ and de/ with translation files inside)
$translate = new Zend_Translate('my_custom_adapter', $dir, null, array('scan' => Zend_Translate::LOCALE_DIRECTORY)); print_r($translate->getList());
prints: Array ( [en] => en [zh_TW] => zh_TW [zh_CN] => zh_CN [de] => de )
DOESN'T WORK: ($dir contains files zh_CN.txt zh_TW.txt en.txt and de.txt)
$translate = new Zend_Translate('my_custom_adapter', $dir, null, array('scan' => Zend_Translate::LOCALE_FILENAME)); print_r($translate->getList());
prints: Array ( [en] => en [de] => de [zh] => zh )
I will continue with DIRECTORY, but I would prefer to use FILENAME, but what am I doing wrong that it combines zh_CN and zh_TW into a single locale?
Posted by Thomas Weidner (thomas) on 2008-04-11T05:19:07.000+0000
Ich habe das Ganze dann mit dem Debugger durchlaufen und das Problem liegt meiner Meinung nach im Code von Zend/Translate/Adapter.php in den Zeilen 124-127:
Wieso wird hier (string) $info anstatt einfach $info->getFilename() verwendet? Durch (string) $info steht bei mir der komplette Pfadname (application/languages/default/de.mo) in $filename, wodurch die Überprüfung Zend_Locale::isLocale($filename) logischerweise false zurückliefert. Dadurch wird dann die Standardsprache gewählt und die messageIds werden immer durch die, der zuletzt verarbeiteten Datei überschrieben.
Will be reviewed...
Posted by Ralf Barth (haggy) on 2008-05-08T05:49:07.000+0000
Directory scanning also seems to be broken. My directory structure is as follows:
<pre class="literal"> languages/ languages/de_DE languages/de_DE/LC_MESSAGES languages/de_DE/LC_MESSAGES/MailAdmin.mo languages/de_DE/LC_MESSAGES/MailAdmin.po languages/en_US languages/en_US/LC_MESSAGES languages/en_US/LC_MESSAGES/MailAdmin.mo languages/en_US/LC_MESSAGES/MailAdmin.po
Zend_Translate failes to retrieve locales in scan path. I'm invoking Zend_Translate this way:
<pre class="highlight"> $translate = new Zend_Translate('gettext', '../application/languages', null, array('scan' => Zend_Translate::LOCALE_DIRECTORY));
Debugging paths while scanning gives the following paths:
<pre class="literal"> string(30) "../application/languages/de_DE" string(42) "../application/languages/de_DE/LC_MESSAGES" string(30) "../application/languages/en_US" string(42) "../application/languages/en_US/LC_MESSAGES"
which obviously don't match any locales. This happens in line 116 of Zend_Translate_Adapter. (string)$info is tested against Zend_Locale::isLocale() which returns false. Also there's the somewhat 'suspicious' line 114:
<pre class="highlight"> $directory = $info->getPath();
for which i do not find any use since $directory is not used in throughout the whole method.
I don't know if this issue is related to PHP or Zend_Translate. I'm using PHP 5.2.6
<pre class="literal"> PHP 5.2.6-0.dotdeb.1 with Suhosin-Patch 0.9.6.2 (cli) (built: May 2 2008 09:37:37) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies with Suhosin v0.9.23, Copyright (c) 2007, by SektionEins GmbH
and Zend Framework v.1.5.1
Hope this helps a bit - Thanks! Ralf.
Posted by Ralf Barth (haggy) on 2008-05-08T06:47:34.000+0000
Proposed patch for Zend/Translate/Adapter.php (solves the directory scan issue).
Beware of your php version - 5.2.2 introduced a new method SPLFileInfo::getBasename() which is used in the patch. A fallback for versions < 5.2.2 is included but commented out.
This is a quick hack which is not tested thoroughly, but worksforme :-)
Posted by Thomas Weidner (thomas) on 2008-05-18T09:53:12.000+0000
Ralf, the problem you have, has nothing to do with the mentioned issue.
Your problem was already fixed on 08.April and duplicates a closed issue. Your patch is not relevant to this problem.
Posted by Ralf Barth (haggy) on 2008-05-21T03:16:52.000+0000
So would you please be so kind to point me to the right issue - because i simply can't find it. If you meant ZF-3215, this simply does not solve the issue because resetting the internal file stack is not my problem...
Posted by Ralf Barth (haggy) on 2008-05-21T03:30:35.000+0000
After a quick check in ZF 1.5.2, the directory scanning is still broken - has your mentioned issue been merged with 1.5.2 ?
Posted by Thomas Weidner (thomas) on 2008-05-23T15:00:03.000+0000
Increased scanning on degraded locales Added tests for file and directory scanning
Posted by Wil Sinclair (wil) on 2008-09-02T10:39:31.000+0000
Updating for the 1.6.0 release.
Have you found an issue?
See the Overview section for more details.