Issues

ZF-3070: Check Filename scanning

Description

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?

Rob

Comments

Possible cause (from the german zfforum):

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.

In der englischen Dokumentation habe ich ausserdem gelesen, dass sich die Sprache auch anhand der Dateiendung identifizieren lässt. Im obenstehenden Code jedoch wird die Dateiendung einfach entfernt ohne diese zu beachten.

Will be reviewed...

UPDATE:

Directory scanning also seems to be broken. My directory structure is as follows:

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:


$translate = new Zend_Translate('gettext', 
    '../application/languages', null, array('scan' => Zend_Translate::LOCALE_DIRECTORY));

Debugging paths while scanning gives the following paths:

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:


$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

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.

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 :-)

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.

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...

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 ?

Increased scanning on degraded locales Added tests for file and directory scanning

Updating for the 1.6.0 release.