Proper handling of untranslated messages

In past the handling of untranslated messages within Zend_Translate was somewhat unhandy.
You had to check if the message can be translated or not, and then you had to notify yourself somehow. This leaded mainly to self written view helpers or an own class as middleware which did this job for you.

So I began thinking and found a really nice solution for you guys which was integrated yesterday.

Think of a site with a huge amount of pages. For simplification you have created the translation sources yourself. You choosed cvs for example. Now your site grows from day to day. Several people are working on it. Of course, depending on the size of the site and how pedantic your helpers are, you would have forgotten to add some messages to the translation files.
For the visitors of your site it seems like you’ve overlooked things and the site seems unfinished and unprofessional because languages are mixed.

There is now a solution to this problem:

You can define that Zend_Translate should write messages which can not be translated into a log. This does even work with your existing code. You just have to add 3 lines. Let’s get into practice:

First, create a log instance:

$writer = new Zend_Log_Writer_Stream('/path/mylog.log');
$log = new Zend_Log($writer);

Then attach it to Zend_Translate:

$t = new Zend_Translate('csv', $path);
    array('log' => $log,
           'logUntranslated' => true));

Additionally we activated logging for messages with the option logUntranslated.
That’s it. From now on, when a message has to be translated and there is no translation found, you will have a log entry which reads Untranslated message: My requested message. Now all you have to do is to check your log regulary and look if there are any untranslated messages.

Better than before, but with this feature you can do even more.
Now you have to add this new translations manually to a translation source file. But Zend_Log could do this for you when you want to invest some lines of code.

All you have to do is to write your own extension of a Zend_Log_Writer. Your Log_Writer instance has to handle the source format you want to use. Strip the leading “Untranslated message: ” from the thrown notice and then write the new message to the file.

As short example:

My_Csv_Log_Writer extends Zend_Log_Writer_Stream
    protected function <em>write($event)
        $event = substr($event, 22);
        return parent::</em>write($event . ";\n");

This just strips out the leading untranslated stuff and add a separator and a new line to the file.
Of course, for a real working implementation this is not enough.

You would have to create a log writer for the source format you want to use. But it should show you how simple a new log writer can be.

As always this new feature is available with the next release which is ZF 1.8 or when you use trunk.
I hope you love this new feature. ;-)

Thomas Weidner
I18N Team Leader, Zend Framework

Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework

Back to top

Validation and formatting of Dates

Hy fellows,

when you are validating Input with Zend_Validate_Date then you can now use the Date constants as validation format. This allows you to validate against localized formats even when you don’t know how the format looks like.

As example:
In past you had to know the format or evaluate it from Zend_Locale like shown:

$locale = 'de';
$format = Zend_Locale::getTranslation('date', array('gregorian', 'medium'), $locale);
$valid = new Zend_Validate_Date($format, $locale);

Now you can simply use the constants from Zend_Date to simplify the validation:

$valid = new Zend_Validate_Date(Zend_Date::DATE_MEDIUM, 'de');

This works with all available date constants.

Also Zend_Date itself can now handle the format constants within the methods which did not support it. You can use them within isDate() which, until now, only accepted fixed ISO format. And you can use them also within the toString() method.

$date = new Zend_Date($myinput);
print $date->toString(Zend_Date::RSS);

While adding this new features I also did some rework of Zend_Date itself. It is now about 200 lines reduced without change to the functionallity. And the parsing is faster than in past.

As always, this new feature is available with the next minor release which will be 1.8.

Thomas Weidner
I18N Team Leader, Zend Framework

Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework

Back to top

It’s Update Time…

No task update since 3 weeks ? That can not be true. :-)

And you’re right… Of course there are several news, but they were too small to write a own entry. Therefor I will give you now a update of what has been done since 14.January.

File uploads:

  • Several people noted that they get an exception when they use the file element. And they noted that they is no filled $_FILES array in this case.

    The reason is simple: When the uploader exceeds the size definition from the php.ini file then the file is not accepted by PHP. As there is no file, PHP deleted it, the file element returns an error.

    The solution for this problem is of course also simple: Let’s use the web-browser to do this check for us. When you set the maximum filesize setMaxFileSize() then the browser checks if the file which should be uploaded exceeds this size.


    Within the next release this size check is automatically set by using the maximum values from the PHP.ini file.

  • 2 new methods have been added:
    getFileSize() returns the real size from the uploaded file. It does not rely on the informations of the $_FILES array.

    getMimeType() returns the real mimetype of the uploaded file. It uses the fileinfo extension or the mime extension for detection.

  • All methods have now support for multifiles: Several methods lacked the support like getErrors, setFilters and some others.

    If you expect problems with multifiles you should use ZF1.8 and higher or trunk.

  • getFileName() supports now also path reduction by it’s second parameter.

    This feature was added for all lacy ones which don’t want to use the getValue() method. ;-)

  • Several people noted in the past that the file element does not work due to false usage of setDecorator at the elements.

    As note: setDecorator() deletes all default decorators. But the file decorator is responsible for the hidden elements needed for file uploads to work properly and also for the correct naming schema.

    As solution to this problem I added a marker interface for the file element. This means as soon as you missuse setDecorator() and forget to add the file decorator before rendering it, an exception will be thrown.

  • In past, when the upload was processed, the file was first moved to the set destination (or the temporary directory), and after that the file was renamed according to the used rename() filter.

    As you can see, in this case, the file is moved twice. Once into the temp directory and then to it’s renamed location. The bigger the file, the more ressource intensive is this task.

    As solution I added a new behaviour: When a rename filter is added, then the destination from this filter is instantly used as moved location instead of moving the file twice.

  • Rob mentioned in his blog that the file element does not really work with the count validator. Specially when using multifiles.

    This really hard to solve bug was finally fixed… now the count validator works on normal file elements, multifiles and also multiple file elements as expected.

Localization informations:

  • I added new informations which can be requested using Zend_Locale’s getTranslationList() methods.
    You can now request 3 digit country codes and also 3 character country codes. These codes are often used within enterprise systems (f.e. banks).

Date detection:

  • I increased the date detection routines. They can now automatically handle 2 digit year notations like 120209 even when you give no format, or a false format. This has an positive effect on the date validator and also to the isDate method.

All above mentioned features are only available in trunk and will be released with ZF 1.8.

Additionally I have already some new features on hold. But they are still under review by the dev-team. So I will inform you as soon as they are cored. And I also added some new proposals, 5 in sum, which are eighter under review or under recommendation.

So I wish you a happy frameworking :-)

Thomas Weidner
I18N Team Leader, Zend Framework

Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework

Back to top