Los usuarios de Ubuntu, pueden encontrarse con un problema al hacer una llamada a la función setlocale() encargada de asignar el idioma correcto para, por ejemplo, llamar a la función getText() y que recoja las traducciones en el idioma correcto.

El problema está en que únicamente podemos cargar los idiomas que están presentes en el sistema operativo y si intentamos cargar uno diferente, setlocale() nos devolverá siempre false.

Podemos saber los idiomas cargados en el sistema operativo mediante el comando:

locale -a

Esto nos devolverá un listado similar a este:

C
en_GB.utf8
en_IN
en_NG
en_US.utf8
POSIX

Si estámos intentando cargar el idioma es_ES (como era mi caso), le resultará imposible… la solución, instalar los idiomas que necesitamos lanzando el comando:

apt-get install language-pack-es-base

Posteriormente, reiniciaremos Apache:

/etc/init.d/apache2 reload

Y le indicaremos a nuestro programa que cargue el idioma con el mismo nombre que lo encontramos en nuestro sistema, es decir, en mi caso:

setlocale( LC_MESSAGES, “es_ES.UTF8″ );

Y con esto conseguiremos que nuestro programa quede internacionalizado de manera correcta.

En alguna ocasión me he encontrado con que no puedo hacer update de un proyecto porque SVN indica el error:

Working copy xxxxxxxx locked Please execute “Cleanup” command

Pero cuando lanzao el comando cleanup también devuelve un error:

Cleanup failed to process the following paths: xxxxxx

Con lo que aparentemente, la única solución que queda es hacer un checkout nuevo e intentar no perder los cambios, sin embargo, existe otra solución:

1. Copia los archivos editados en otra carpeta para evitar perder los cambios
2. Borra la carpeta que esté causando el problema
3. Ahora podrás hacer update
4. Copia los archivos editados en la carpeta (no copies las carpetas enteras porque contienen directorios .svn que volverán a darte problemas)
5. Por último, haz commit

Espero os sea de utilidad.

Via | Abstruse Goose

Uno de los errores comunes al implementar Smarty3 es:

Fatal error: Class ‘Smarty_Internal_Wrapper’ not found

Fatal error: Class ‘Smarty_Internal_Register’ not found

Fatal error: Class ‘Smarty_Internal_Template’ not found

Estos se deban, probablemente, a que en tu aplicación estás utilizando la función __autoload también necesaria por Smarty3. La solución a este problema pasa por utilizar la función que PHP nos brinda spl_autoload_register.

En una aplicación, sólo puede existir una llamada a la función __autload, sin embargo, con spl_autoload_register podemos añadir tantos manejadores como queramos y estos se irán ejecutando en el orden en el que los hayamos registrado.

Un ejemplo sencillo de su uso sería:

class AutoloadHandler
{
	static public function launch( $classname )
	{
		print '[['. $name .']]';
	}
}

spl_autoload_register( 'AutoloadHandler::launch' );

new ThisClassNotExists();

El resultado de ejecutar este script sería algo así:

[[ThisClassNotExists]]

Fatal error: Class ‘ThisClassNotExists’ not found in …

El cual nos indica que está llamando de manera correcta al autoload, pero al no estar implementado de manera correcta y no existir la clase ‘ThisClassNotExists’ nos devuelve un error.

En definitiva, para solventar el problema, no será necesario que modifiques el código Smarty, pues este ya está utilizando de manera correcta spl_autoload_register, lo que debes hacer es sustituir tu __autoload por una clase con una función ‘launch’ (llámala como quieras) y registrarla mediante:

<pre>spl_autoload_register( 'MyAutoloadHandler::launch' );</pre>

Si estás utilizando Smarty2 y te has decidido a dar el salto a Smarty3 para aprovecharte de sus nuevas funcionalidades (como por ejemplo la nada despreciable opción de herencia en templates), verás que existen algunas incompatibilidades, por ejemplo, se han decidido por seguir el estandar camelCase en el nombre de las funciones, utilizan getters y setters para los atributos o han cambiado la manera de registrar bloques.

En el caso del popular plugin smarty-gettext, si tenemos personalizada la llamada al traductor con, por ejemplo ‘{t}’ como es mi caso, nos encontraremos con un bonito error:

function call ‘register_block’ is unknown or deprecated

Esto es debido a que la forma correcta de registrar bloques en Smarty3 es:

$this->register->block('t', 'translate');

en lugar de:

$this->register_block( 't', 'translate' );

Una vez hecho esto, el siguiente error que nos deja Smarty es:

Plugin “t” not callable

En lugar del antiguo ‘translate’, el segundo parámetro deberá ser el nombre correcto de la función, es decir ’smarty_translate’:

$this->register->block('t', 'smarty_translate');

de este modo solventaremos el problema y podremos seguir disfrutando de nuestro plugin de traducción.

Antes de empezar a hacer el upgrade de symfony debemos asegurarnos que los plugins utilizados actualmente en el proyecto son compatibles con la versión 1.4, en caso de no ser compatibles, tenemos tres opciones:

1. Buscar un plugin similar que sí sea compatible.
2. Modificar nuestra aplicación para que no utilice dicho plugin.
3. Si no podemos prescindir de él, habrá que esperar a que saquen la compatibilidad o hackearlo nosotros mismos (lo qual podría ser muy fácil o muy difícil en función del tipo de problema).

Pasos a seguir para subir de versión:

1) Update de los canales de pear

sudo pear update-channels

2) Upgrade de symfony a la versión 1.3

sudo pear upgrade -f symfony/symfony-1.3.0

3) Validamos que no estamos usando métodos deprecated (estós están eliminados en la versión 1.4)

symfony project:validate

En caso de obtener errores del validador, los solventaremos antes de hacer el upgrade siguiendo instrucciónes en la página Deprecations and removals in 1.3

4) Upgrade del projecto a la versión 1.3

symfony project:upgrade1.3

5) Upgrade de los plugins a la última versión

symfony plugin:upgrade [plugin]

6) Upgrade de symfony a la última versión

sudo pear upgrade symfony/symfony

7) Limpiamos la caché antes de probar

symfony cc

Ahora deberíamos tener nuestro proyecto updateado a la última versión estable de symfony

Symfony permite varios métodos para internazionalizar nuestra aplicación. Por defecto, utilizan el formato XLIFF sin embargo, personalmente me gusta más gettext.

¿Cómo configurar symfony para usar gettext?

Para configurar symfony para que utilice gettext seguiremos los siguientes pasos:

1) Activamos el módulo I18N modificando el archivo settings.yml:

#apps/<appName>/config/settings.yml
all:
  .settings:
    charset:                utf-8
    i18n:                   on
    standard_helpers:       [ [TUS_HELPERS_ACTIVADOS]..., I18N]

2) Abrimos el archivo factories.yml y añadimos la entrada i18n:

#apps/<appName>/config/factories.yml
all:
  i18n:
    class: sfI18N
    param:
      default_culture:  en_US
      source:           gettext</pre>

3) Crearemos una carpeta i18n dentro de apps//:

apps/<appName>/i18n/<lang>

Donde <lang> será el idioma en dos letras (en, es, fr…) y dentro tendremos los ficheros messages.po y messages.mo.

Ahora podemos utilizar la función __( ‘texto_a_traducir’ ) con doble underscore [ _ ] en lugar del simple utilizado normalmente.

¿Cómo generar automáticamente nuestros ficheros po y mo?

Symfony trae una serie de herramientas que nos permiten generar los archivos po y mo de manera automática. Invocando el comando:

symfony i18n:extract frontend en --auto-save

Se recorrerá todos los archivos php de nuestra aplicación (código y templates) y sacará los textos que encuentre en las funciones __().

También se puede utilizar el mismo comando de la siguiente manera:

symfony i18n:extract frontend en --auto-delete

para eliminar las cadenas de texto que ya no existen.

Una sencilla función que dado un número de segundos, nos devuelve el tiempo en formato hh:mm:ss

protected function makeTimeFromSeconds( $total_seconds )
{
    $horas              = floor ( $total_seconds / 3600 );
    $minutes            = ( ( $total_seconds / 60 ) % 60 );
    $seconds            = ( $total_seconds % 60 );

    $time['horas']      = str_pad( $horas, 2, "0", STR_PAD_LEFT );
    $time['minutes']    = str_pad( $minutes, 2, "0", STR_PAD_LEFT );
    $time['seconds']    = str_pad( $seconds, 2, "0", STR_PAD_LEFT );

    $time               = implode( ':', $time );

    return $time;
}

Espero os sea de utilidad.

Aquí os dejo algo de información sobre como solicitar variables de configuración en symfony además de un listado muy útil con todas las variables que Symfony trae predefinidas.

Cómo pedir variables definidas

Se puede llamar a la función estática get del objeto sfConfig para solicitar cualquier variable definida pasándo dos valores. El primero indica el nombre de la variable solicitada y el segundo, el valor que retornará en caso de no existir dicha variable.

sfConfig::get('sf_config_variable', 'The default value'); // The default is optional

Además de las variables que symfony trea configuradas por defecto, podemos añadir nuestras propias variables. Esto se hace en los archivos app.yml. Tenemos un app.yml global para todas las aplicaciones y módulos de nuestro proyecto localizado en:

/path/to/project/[PROJECT_NAME]/config/app.yml

y otro para cada una de las aplicaciones:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/config/app.yml

NOTA! Si existen dos variables con el mismo nombre en el app.yml global y en el de aplicación, este último valor sobreescribirá el valor global.

Para solicitar una variable definida en uno de estos archivos app.yml devemos añadir app_ al nombre de la variable como se muestra en el siguiente ejemplo:

sfConfig::get('app_sf_config_variable');

Si en el archivo app.yml definimos la variable en cascada, como por ejemplo:

all:
  admin:
    email: admin@mail.bla

Deberemos acceder a ella añadiendo los diferentes niveles en la llamada:

sfConfig::get('app_admin_email');
También podemos acceder a los valores configurados en settings.yml añadiendo el prefijo “sf_” al valor que queremos recuperar.

Variables definidas por Symfony Framework

sf_symfony_lib_dir

Path real a la carpeta lib del framework:

/usr/share/php/symfony/symfony12/lib

Project Structure and Layout

sf_root_dir

Path a la raiz del projecto:

/path/to/project/[PROJECT_NAME]

sf_apps_dir

Path a la carpeta “apps” del proyecto:

/path/to/project/[PROJECT_NAME]/apps

sf_lib_dir

Path a la carpeta “lib” del proyecto:

/path/to/project/[PROJECT_NAME]/lib

sf_log_dir

Path a la carpeta “log” del proyecto:

/path/to/project/[PROJECT_NAME]/log

sf_data_dir

Path a la carpeta “data” del proyecto:

/path/to/project/[PROJECT_NAME]/data

sf_config_dir

Path a la carpeta “config” del proyecto:

/path/to/project/[PROJECT_NAME]/config

sf_test_dir

Path a la carpeta “test” del proyecto:

/path/to/project/[PROJECT_NAME]/test/

sf_doc_dir

Path a la carpeta “doc” del proyecto:

/path/to/project/[PROJECT_NAME]/doc

sf_plugins_dir

Path a la carpeta de “plugins” del proyecto:

/path/to/project/[PROJECT_NAME]/plugins

sf_cache_dir

Path a la carpeta “cache” del proyecto:

/path/to/project/[PROJECT_NAME]/cache

sf_web_dir

Path a la carpeta pública “web”:

/path/to/project/[PROJECT_NAME]/web

sf_upload_dir

Path a la carpeta pública de “uploads”:

/path/to/project/[PROJECT_NAME]/web/uploads

Application Information

sf_app

El nombre de la aplicación en la que está el archivo, como por ejemplo “frontend” o “backend”.

sf_environment

Entorno de desarrollo actual como por ejemplo “dev”.

sf_debug

Devuelve el estado actual del modo debug. Puede estar activado “1″ o desactivado “0″.

Application Structure and Layout

sf_app_dir

Path a la carpeta de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]

sf_app_config_dir

Path a la carpeta “config” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/config

sf_app_lib_dir

Path a la carpeta “lib” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/lib

sf_app_module_dir

Path a la carpeta “modules” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/modules

sf_app_template_dir

Path a la carpeta “templates” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/templates

sf_app_i18n_dir

Path a la carpeta “i18n” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/i18n

Cache Structure and Layout

sf_app_base_cache_dir

Path a la carpeta de la aplicación actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]

sf_app_cache_dir

Path a la carpeta de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev

sf_template_cache_dir

Path a la carpeta “template” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/template

sf_i18n_cache_dir

Path a la carpeta “i18n” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/i18n

sf_config_cache_dir

Path a la carpeta “config” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/config

sf_test_cache_dir

Path a la carpeta “test” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/test

sf_module_cache_dir

Path a la carpeta “modules” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/modules

Application Settings

sf_error_404_module

Módulo que ha hecho saltar el error 404.

sf_error_404_action

Acción que ha hecho saltar el error 404.

sf_logging_enabled

Valor boleano que nos indica si el loggin de la web está activo “1″ o no “0″.

sf_escaping_strategy

Valor boleano que indica si la clase sfView está usando Escaping Strategy “1″ o no “0″.

sf_no_script_name

Valor boleano que indica si la aplicación requiere nombre de script.

sf_csrf_secret

La clave CSRF secreta configurada en la aplicación.

También:

Se puede acceder a la información del actual contexto con las siguientes funciones:

sfContext::getInstance()->getActionName();

Devuelve el nombre de la acción actual. También puede llamarse desde los templates con $this->getActionName().

sfContext::getInstance()->getModuleName();

Nombre del módulo actual. También puede llamarse desde los templates con $this->getModuleName().

sfContext::getInstance()->getModuleDirectory();

Path al directorio del módulo actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/modules/[MODULE_NAME]

Veo en el blog de 20 minutos la siguiente viñeta que identifica las webs más populares del momento con personas.