YASB – Yet Another Symfony Blog

May 20, 2007

Using jQuery to manipulate a foreign DOM

Filed under: Browsers, HTML, Javascript, Tips and tricks — Krof Drakula @ 9:39 am

This is somewhat of an old topic, but digging through a myriad of ways of including jQuery into a website that doesn’t use it (eg. Wordpress having Prototype and such), I stumbled upon a bookmarklet written by John Resig that loads jQuery into the current DOM and enables you to run an onload function that executes when the library’s ready to use.

Here’s the page where the process is documented with an example of manipulating Digg using jQuery. The approach used with this bookmarklet is useful because it enables you to turn on the noConflict mode without manually waiting for the library to load. You do this by replacing the comment fragment in the bookmarklet with jQuery.noConflict() inside the onload handler and hey presto! you have jQuery enabled and available via jQuery.*.

May 11, 2007

Easier I18n XLIFF message generation

Filed under: General, PHP, Tips and tricks — Krof Drakula @ 1:43 pm

If you’re like me and you don’t trust yourself to catch all of the breadcrumbs you leave behind you, you tend to rely on an arsenal of tools to keep you in check. This is especially true with XLIFF and Symfony.

There’s an i18n generation script that scans your actions, YAMLs and templates for the use of the __() function. The scanner routine is pretty robust and only adds missing entries, but leaves others intact. A great tool if you’re translating applications.

But there’s a problem: when you try to write your own validators and have I18n enabled in your application, the sfRequest::setError() expects 2 parameters: the name of the request parameter and the value of the error, the problem here being that ::setError() expects the second parameter to be the source language for translation, which in turn means that you don’t need to use __() to wrap your error message, so that it works directly with your validation YAML files.

That’s very smart, because you don’t have to translate your YAML validation files, since it already wraps it in __(). But not good, if you want to generate your own XLIFF files and not use the __() function (since the current implementation only scans for occurences of that function).

The problem was elegantly solved by fatg, who proposed testing the script for the detection of *__() functions – and it works. So, if you’re using any function which ends with __, the init-i18n script WILL detect it and add it to the XLIFF.

But how exactly does that solve anything? Well, instead of writing something like:

// lang php
$this->getRequest()->setError("my_parameter", "my_error");

…you write:

// lang php
$this->getRequest()->setError("my_parameter", i18n__("my_error"));

Okay, so the script now detects "my_error" as being an XLIFF source, but the application will fail with a fatal error in this case. That part is easily solved by adding

// lang php
function i18n__($message) { return $message; }

to apps/[myapp]/config/config.php, which creates the i18n__() function within the myapp application.

Although this isn’t the ideal solution (it would be nice if Symfony auto-generated the XLIFF by itself when using the __() function), it’s way better than duplicating the source keys inside comments like:

// lang php
// __("this is a source string");

Not only is it a pain to edit, it bloats the code significantly.

Anyways, hats off to fatg. Nice work.

May 9, 2007

Solved: How to get I18n working on reverse-engineered tables

Filed under: Database, PHP, Propel — Krof Drakula @ 12:24 pm

We’ve all been there – Symfony and I18n do play well together – it’s got XLIFF for interface translation which works almost out-of-the-box, it’s got localization features for things like numbers, currencies and many others. It also has internationalization features that work with database tables.

Unfortunately, all is well until you stray from the guidelines presented in the Symfony book. The norm in Symfony is to write the database definition withing the schema.yml file. That’s okay… it’s compact, concise and verbose enough to be understood within the context of Symfony nomenclature. But when you’re dealing with 25+ tables that need accompanying I18n tables, things could get messy, nomenclature or not.


Powered by WordPress