¿Que es la Internacionalización?

La Web se ha convertido en la principal herramienta de difusión de información para una audiencia variada y de gran tamaño que requiere de un procesamiento de información sencillo. La información que se muestra al usuario está compuesta de partes diferentes que han de trabajar en conjunto de forma coordinada para que la información sea accesible y universal, es decir, estas partes que integran la Web han de funcionar bajo cualquier circunstancia, en cualquier país, con cualquier idioma y cultura. Por este motivo la internacionalización podría definirse como un proceso a través del cual se van a diseñar sitios Web adaptables a diferentes idiomas y regiones sin necesidad de realizar cambios en el código. La utilización de formatos y protocolos que no establezcan barreras a los diferentes idiomas, sistemas de escritura, códigos y otras convenciones locales, es esencial para hablar de internacionalización en un sitio Web.

La Internacionalización también es conocida como I18N, que es la abreviatura de Internacionalización porque hay 18 letras entre la i y la n. Fuente.

Otro aspecto importante es saber como funciona la internacionalización.

Norma N. 1 – TODO EN UTF-8: editor, archivos, BD, tablas, campos, es decir todo, esto soluciona el 90% de los problemas de i18n.

Recordar que este ejemplo esta adaptado para KumbiaPHP, aunque la generación de los catalogos es igual en cualquier caso, la recomendación es usar Gettex fácil de usar y estándar, hay un tutorial en la Wiki de KumbiaPHP (KumbiaPHP y Gettext)el cual explica como generar los catalogos con Poedit y donde ubicarlos dentro de la estructura de directorio de la versión 1.0 Beta1

El autor del blog Matando Tigres ha creado su receta que como comente es bastante simple y funcional, yo traigo otra alternativa tan igual de fácil como esa ;).

Es sumamente importante generar los catalogos tal como se explica en el tutorial KumbiaPHP y Gettex ya que la intención de este tutorial es como mediante las URL’s sabemos el idioma y aplicarlo a nuestra aplicación para que se hagan las traducciones necesarias.

Lo Primero

Lo que deseamos es tener una URL como esta http://dominio.com/$lang/controller/action/, donde el $lang puede tener tantos idiomas como se hayan considerado.

Siguiendo, hay que editar el archivo app/public/.htaccess hay muchos que ignoran el gran potencial que se cuenta con la reescrituras de URL (mod_rewrite) y para efecto de este tutorial quiero sacar provecho de las reglas de reescritura.

... AQUI ESTA EL DEMAS CONTENIDO...
    # Para peticiones que no son archivos ni directorios
    # Reescribe a index.php?_url=URL
    RewriteRule ^(es|en)/(.*)$ index.php?url=/$2&lang=$1 [QSA,L]

Como se aprecia solo hemos cambiado la última regla para agregar el idioma y este luego es enviado como un parámetro GET['lang'] y como se mencionó la URL tendra este aspecto http://dominio.com/es/controller/action/ para efecto del ejemplo solo se han colocado 2 idiomas es (español) y en (ingles) pueden estar todos los que se necesiten.

Lo Segundo

Adecuar todos los enlaces, esto lo hacemos editando el FrontController de KumbiaPHP app/public/index.php en la definición de la constante URL_PATH que es la constante que se colocan en los link, form, etc. generados por los helpers.

La definición de esta constante esta aprox. por la línea 75.
define(‘URL_PATH’, PUBLIC_PATH.$_GET['lang'].’/');

Como se aprecia solo hemos agregando el valor del parámetro $_GET['lang'] que se definió en el .htaccess con esto ya todos nuestros enlaces tienen el idioma en la URL.

Por último…

Ahora solo queda asignar el valor del lenguaje solicitado para que la aplicación lo cargue y aplique las traducciones necesarias, ¿recuerdan lo que escribí hace un tiempo de aprovechar el método initialize()? para este caso también aplica :).

class ApplicationController extends Controller
{
    /**
     * Array con los idiomas disponibles
     */
    private $_langs = array('es' => 'es_VE', 'en' => 'en_US');
    public function initialize()
    {
        $lang = $_GET['lang'];
        //verifica que el lenguaje sea soportado, sino existe tomamos uno por defecto 'es_VE'
        if(!array_key_exists($lang, $this->_langs){
            //idioma por defecto
            $lang = 'es_VE';
        }else{
            $lang = $this->_langs[$lang];
        }
        putenv("LC_ALL=$lang");
        setlocale(LC_ALL, $lang);
        bindtextdomain("messages", APP_PATH . 'locale');
        textdomain("messages");
    }
}

Con esto ya deben funcionar las traducciones de nuestra aplicación, los código de idiomas sale del ISO 631-1

Conclusiones…

i18n es mas que una traducción de texto a un idioma hay que tomar en cuenta las culturas de las traducciones, monedas, fechas, montos, etc. hay muchas cosas por tomar en cuenta que no mencione en este tutorial sin embargo con ir al sitio oficial de Internacionalización (ingles) de la W3C encontraran bastante insumos para comprender este tema.

Haciendo una pequeña comparación respecto al ejemplo que publico el autor del blog Matando Tigres es que en este caso no utilizo el routes.ini obviamente esto se traduce en un tema de performance y reducción de trabajo, porque tantas rutas estaticas tenga en mi sistema debo definirla para el idioma.

Como siempre digo es una opción que seguro irá mejorando a medida que ustedes den un feedback, espero sus comentarios.

Actualizado 11 de Junio 2010

En este tutorial explcaré el comportamiento de KumbiaPHP cuando hacemos aplicaciones ricas en JavaScript, me basare en utilizar jQuery como framework de JavaScript y no daré una explicación muy amplia de que son peticiones asíncronas ni como funcionan estas esto porque hay suficiente información en la red para quienes deseen indagar un poco mas, simplemente nos dedicaremos hacer peticiones asíncronas dentro de KumbiaPHP.

Como todo ejemplo lo ideal es basarlo en hechos reales y cotidianos en este sentido haremos un cliente que acorte URL utilizando el API del servicio SigueMiLink el cual fue desarrollado con KumbiaPHP :).

Requisitos

Antes de continuar hay que verificar lo que necesitamos para llevar acabo el tutorial.

• Tener funcionando KumbiaPHP Beta1 (Instalar KumbiaPHP)
• Descargar jQuery y colocarlo en el directorio app/public/javascript/jquery/jquery-1.4.2.min.js.
• Por lo menos haber hecho el ejemplo Hola Mundo de KumbiaPHP para entender este tutorial.
• Leer un poco el API del servicio SigueMiLink
• Ver funcionamiento básico de KumbiaPHP con AJAX

Empezamos

Lo primero es crear el controlador para efecto de este tutorial lo llame api mirar las convenciones de nombres de controladores si se te ocurre otro nombre mejor usalo, pero piensa que a lo largo del tutorial haré mención al controller api.

<?php
/**
 * Controller para utilizar el API de SigueMiLink
 * @author Deivinson Tejeda <deivinsontejeda@kumbiaphp.com>
 */
class ApiController extends ApplicationController
{
    /**
     * URL del API de SigueMiLink
     */
    private $_urlAPI = 'http://www.siguemilink.com/api/%s/?destination=%s';
    /**
     * Callback Before que verifica si la petición es Asíncrona...
     */
    public function before_filter()
    {
        if($this->is_ajax()){
            $this->set_response('view');
        }
    }
    /**
     * Form que se comunica con el API de SigueMiLink
     * para acortar el enlace
     *
     */
    public function acortar()
    {
        if($this->has_post('url')){
            //Reemplazo de valores en la URL del API.
            $this->_urlAPI = sprintf($this->_urlAPI, 'create', $this->post('url'));
            $this->response1 = json_decode(file_get_contents($this->_urlAPI));
            $this->render('response');
        }
    }
}

Ahora se crea la vista app/views/api/acortar.phtml que tiene un formulario que envia la URL al controller que será enviada al API de SigueMiLink.

<div style="margin: auto">
    <?php echo form_tag(array('api/acortar/', 'class'=>'form-remote')) ?>
        <label>Acorte tu enlace</label>
        <?php echo text_field_tag(array('url')) ?>
        <?php echo submit_tag('Enviar') ?>
    <?php echo end_form_tag() ?><br />
    <div id="update" style="margin: auto;"></div>
</div>
 
<?php echo javascript_include_tag('jquery/jquery-1.4.2.min'); ?>
<script type="text/javascript">
    <!--//--><![CDATA[//><!--
        $(function() {
            $(".form-remote").live('submit', function(event){
                event.preventDefault();
			    self = $(this);
			    var button = $('[type=submit]', self);
			    button.attr('disabled', 'disabled');
			    var url = self.attr('action');
			    //var div = self.attr('data-div');
			    $.post(url, self.serialize(), function(data, status){
				    var capa = $('#update');
				    capa.html(data);
				    capa.hide();
				    capa.show('slow');
				    button.attr('disabled', null);
			    });
            });
        });
    //--><!]]>
</script>

Creamos la vista que tiene la respuesta enviado desde el servicio que acorta la URL app/views/api/response.phtml

<?php if($response1->code == 2):?>
    <a href="http://smlk.es/<?php echo $response1->link?>/">http://smlk.es/<?php echo $response1->link?>/</a>
<?php else: ?>
    <strong>No se pudo acortar el enlace</strong>
<?php endif; ?>

Lo genial de este ejemplo es que funciona con o sin javascript para promover la accesibilidad web. Ahora explico un poco lo que hace el controller api, el método before_filter() es un filtro que se ejecuta antes de la acción en este caso verificamos si la petición es asíncrona y de serlo damos respuesta asíncrona, útil para centralizar y si la aplicación es muy rica en javascript no se tendra que tener esta validación en cada action del controller ;).

La action acortar() muestra el form y envia la petición (cuando se hace el submit) al servicio SigueMiLink para acortar la URL, con el método render() cambiamos de vista a renpose y como la petición se ha hecho asíncrona ya saben lo demas :).

En la vista acortar.phtml tenemos el formulario y con un JavaScript para enviar la petición asíncrona, en la documentación de jQuery se explican los métodos usados en este ejemplo en los cuales no me enfocare.

Es importante indicar el elemento del DOM que se actualizará luego de la petición, en este caso es un div con un identificador (id) update.

Es de notar que en la vista response no se analizan todos los códigos de error que devuelve el API de SigueMiLink, como tarea pueden hacer esto y dar respuesta al usuario de acuerdo al error retornado del servicio.

Importante

• Si no indicas que la respuesta será asíncrona KumbiaPHP cargará todo el template y por ende habran elementos de la vista que veras repetidos, así que no olvides el $this->set_response(‘view’).
• Saber que elemento del DOM se va actualizar

A probar lo hecho

Así es, nos queda probar lo que se hizo y mirar que todo ande como lo planeado, es decir un formulario con un campo de texto donde se coloca la URL que deseamos acortar al dar click en el submit si todo estuvo bien nos retorna una URL acortada para compartirla en nuestras redes sociales…

Asumiendo que tienes una instalación local deberías ver el ejemplo pinchando una URL como esta http://localhost/kumbiaphp/api/acortar/ es importante entender las URL de KumbiaPHP

En la Wiki de KumbiaPHP hay un ejemplo mas simple de como integrar jQuery en KumbiaPHP y puede quedar mucho mejor este tutorial por ejemplo tener un modelo que se consuma todo el web service del API de SigueMiLink, pero ya esto es tarea de lo mas curiosos les dejo un post que escribí sobre los modelo dentro del MVC

¿dudas? ¿sugerencias? deja tu comentario y ayuda a mejorar este ejemplo…

El enrutamiento es un mecanismo que reescribe las URL para simplificar su aspecto. Antes de poder comprender su importancia, es necesario dedicar unos minutos al estudio de las URL de las aplicaciones web.

Ejecutando Acciones en el Servidor mediante URL.

Las URL se encargan de enviar la información desde el navegador hasta el servidor. Las URL tradicionales incluyen la ruta hasta del script del servidor y algunos parámetros necesarios para completar la petición, como se muestra en el siguiente:

http://www.dominio.com/controlador/noticia.php?id=123456

La URL anterior revela informacion sobre la arquitectura interna de la aplicacion incluso de la BD, esto es algo que todo desarrollador de software debe evitar, veamos los detalles tecnicos:

• En la URL anterior, ¿que pasaria si un usuario malicioso (6) cambia el valor del parametro id? ¿Supone este caso que la aplicación ofrece una interfaz directa a la base de datos?, lo que intento decir que con esta URL nos podemos poner muy “esotérico“, volviendose casi imposible aplicar seguridad.
• Una URL como la anterior es muy dificil de leer, y estas no solo se muestran en la barra de direcciones de los browser, ademas son las que se indexan en los principales buscadores cuando los usuarios buscan informacion, por eso es mas simple ofrecer URL sencillas para que sean entendibles.
• Si se modifica una URL (porque cambia el nombre del script u otra cosa), se deben modificar todos los enlaces a esa URL (esto trae consecuencias terrorificas). De esta forma, las modificaciones en la estructura del controlador son muy pesadas y costosas, lo que contradice la filosofía del desarrollo ágil de aplicaciones.

La URL como Interfaz.

Una de las ideas del sistema de enrutamiento es utilizar las URL como parte de la interfaz. Las aplicaciones trasladan información al usuario mediante el formateo de las URL y el usuario puede utilizar las URL para acceder a los recursos de la aplicación.

Esto es posible en KumbiaPHP porque la URL no guarda necesariamente relación con las instrucciones del servidor. En su lugar, la URL está relacionada con el recurso solicitado, y su aspecto puede configurarse libremente de manera muy fácil.

http://blog.temiga.org/noticias/enrutamiento_en_kumbiaphp/

Esta URL tiene muchas ventajas:

• Las URL tienen significado y ayudan a los usuarios a decidir si la página que se cargará al pulsar sobre un enlace contiene lo que esperan. Un enlace puede contener detalles adicionales sobre el recurso que enlaza.

• Se puede modificar el aspecto de la URL y el del nombre de la acción o de los parámetros de forma independiente y con una sola modificación.
• Aunque se modifique la estructura interna de la aplicación, las URL pueden mantener su mismo aspecto hacia el exterior.
• Son más seguras. Cualquier URL no reconocida se redirige a una página especificada por el programador y los usuarios no pueden navegar por el directorio raíz del servidor mediante la prueba de diferentes URL.

Veamos como funciona.

Como hemos hablado KumbiaPHP no guarda relacion con las URL externas y las URI utilizadas internamente (ya conocemos algunas ventajas) la corresponsabilidad entre ambas es trabajo del Sistema de Enrutamiento (Router), esto se simplifica utilizando una sintaxis para URI internas muy parecidas a las externas, ejemplo:

; URI Interna
/articulos/* = controller/action/*

; NOTA controller y action respresentan quienes se encargaran de atender esa regla

;URL externa tendra esta forma
; http://www.dominio.com/articulos/una_noticia_cualquiera/

El sistema de enrutamiento utiliza un archivo de configuración, llamado routes.ini, en el que se pueden definir las reglas de enrutamiento. Si se considera la regla mostrada arriba, se define un patrón cuyo aspecto es articulos/*.

Todas las peticiones realizadas KumbiaPHP son analizadas en primer lugar por el sistema de enrutamiento. El sistema de enrutamiento busca coincidencias entre la URL de la petición y los patrones definidos en las reglas de enrutamiento estatico. Si se produce una coincidencia, las partes del patrón que tienen nombre se transforman en parámetros de la petición y se juntan como parametros de la accion del controller.

// El usuario solicita la siguiente URL externa

http://www.dominio.com/articulos/una_noticia_cualquiera/

// El Router comprueba que coincide con la regla /articulos/*
// El sistema de enrutamiento crea los siguientes parámetros de la petición
  'module'  => 'null'
  'controller'  => 'controller'
  'action'  => 'action'
  'paramater'    => 'una_noticia_cualquiera'

Luego que se descompone la URL, se pasa al controller “controller” y action “action” que recibe un parametro con el valor “una_noticia_cualquiera“, que internamente hara lo necesario para obtener esa noticia solicitada.

class ControllerController extend ApplicationController
{
    //método al cual se enruta
    public function action  ($noticia){
        echo $noticia; //salida una_noticia_cualquiera
   }
}

Conclusiones.

Sin  que utilizar el Sistema de Routing es un gran aliadoy  siempre hay que tener bien claro que una URL no debe guardar relación con la arquitectura de software del lado servidor siendo parte fundamente en el uso de buenas prácticas de desarrollo

Resulta bastante difícil, de acuerdo a mi experiencia y el roce que he tenido con personas del área, ir de la teoría a la implementacion del concepto de lo que es MVC parece ser una camino ofuscado en el que muchos se pierden. La gran mayoría suele decir “estoy claro en lo es MVC…”, pero cuando se ve la aplicabilidad se termina dando cuenta que lo que dijó “estoy claro…” es inversamente proporcional.

Filosofía de un Modelo

Estos son “Lógica de Negocio” y son parte fundamental para el momento que se desarrolla una aplicación, un buen uso de estos nos permiten un gran poder al momento que se necesita escalar, mantener y rehusar código en una aplicación.; es un concepto muy simple, pero la complicacion esta en comprender lo que significa “Logica de Negocio” ya que muchos piensan que la única forma de tener “Lógica de Negocio” va estrecha y únicamente relacionada con una conexión de Base de Datos y esto no es asi!

La práctica mas común (en todos los niveles, no solo me refiero a usuarios novatos) es que dejan la lógica en los controladores, a medida que se deja código de la lógica de negocio en un controlador trae consecuencias garrafales a largo plazo siendo imposible su reutilizacion, traduciendoce en una mala implementacion (código espaguetti). Lo antes expuesto no es precisamente lo que fomenta MVC y POO donde la idea fundamental es el orden y reutilización del código.

Veamos un par de ejemplos para contextualizar.

El primero es un Modelo donde su lógica de negocio esta en una Base de Datos y por ende necesitamos una conexion a motor para trabajar con esa fuente de datos.

class Articulos extends ActiveRecord {
	public function ver($page=1,$ppage=10){
		return $this->paginate('order: creat_at desc',
					"page: $page",
					"per_page: $ppage");
	}
	public function ultimos($limit=10) {
		$today = date('now');
		return $this->find('order: creat_at desc',
				   "conditions: data >= $today",
                                    "limit: $limit");
        }
}

Lo que mencionamos arriba sobre la re-utilización de código y característica fundamental de la POO, si vemos el método ultimos() del modelo Articulos nos sirve para crear un RSS, widget (Partial en KumbiaPHP) con los artículos recientes, etc. es decir donde se necesite los últimos artículos.

El segundo es un Modelo para el manejo de fotos y su la lógica de negocio no esta ligada a una BD.

<?php
/**
* Carga la libreria upload
**/
Load::lib('upload');
/**
* Carga la libreria wideimage
**/
//Load::lib('wideimage');
/**
* Modelo para manipular las fotos de las personas
*
**/
class Foto
{
    /**
* Guarda la foto de una persona
*
* @param string $id id de la foto al guardar
* @param string $file nombre de la foto
* @return boolean
**/
    public function save ($id, $file)
    {
        if ($_FILES[$file]['error'] > 0) {
            Flash::error('Error: No se ha logrado subir el archivo');
            return false;
        }
        if (! in_array($_FILES[$file]['type'], array('image/jpeg' , 'image/pjpeg' , 'image/gif' , 'image/png'))) {
            Flash::error('Error: Solo se admiten imagenes JPEG, PNG y GIF');
            return false;
        }
        if ($_FILES[$file]['size'] > 600 * 1024) {
            Flash::error('Error: No se admiten imagenes superiores a 600KB');
            return false;
        }
        if (Upload::image($file, "$id.jpg")) {
            $file_path = APP_PATH . "public/img/upload/$id.jpg";
            // con marca de agua
            // $watermark = wiImage::load(APP_PATH . "public/img/logo.png");
            // wiImage::load($file_path)->resize(160, 213, 'fill')->merge($watermark, 40, 175)->saveToFile($file_path);
            wiImage::load($file_path)->resize(160, 213, 'fill')->saveToFile($file_path);
            chmod($file_path, 0777);
            return true;
        }
        return false;
    }
    /**
* Busca la foto y en caso de que exista retorna la ruta relativa respecto al directorio de imagenes
*
* @return string $id
* @return string
**/
    public function get ($id)
    {
        if (is_file(APP_PATH . "public/img/upload/$id.jpg")) {
            return "upload/$id.jpg";
        }
        return null;
    }
    /**
* ELimina la foto del usuario
*
* @return string $id
* @return string
**/
    public function delete ($id)
    {
        $filepath = APP_PATH . "public/img/upload/$id.jpg";
        if (is_file($filepath)) {
            return unlink($filepath);
        }
        return false;
    }
}

Como se aprecia en este segundo modelo no existe ninguna conexión a una BD y sigue teniendo lógica de negocio para la aplicación, esta historia también se puede repetir para un modelo de sessión, o como me comento el amigo Jesus Lara (Phenobarbital) tiene modelos que gestionan todas las operaciones de un servidor SAMBA.

Como Usar los Modelos en KumbiaPHP

Ya es un hecho KumbiaPHP llega a su 1er Encuentro de Kumbieros en Maracay – Venezuela, esto nace producto de la misma comunidad en querer encontrarnos y compartir experiencias sobre el proyecto. Esta iniciativa que nació como KumbiaPHP Party & Beers y ya a estas alturas se ha convertido en un evento.

Para ese día tenemos planeado dictar talleres introductorios sobre KumbiaPHP, de la mano de los desarrolladores del Framework y miembros de la comunidad (Próximamente publicaremos el temario de las charlas y/o talleres).

La cita es el Sábado 05 de Diciembre del 2009 a partir de las 09:00 a.m. en Calle Sucre, Complejo Cultural Santos Michelena, Edificio Bibliotecas Virtuales de Aragua, Maracay Edo. Aragua

Como la idea inicial fue un Beers no la hemos dejado de lado, así que al final del evento habrá un Beers (cervezada) que aun no hemos elegido un sitio pero están invitados los que así lo deseen.

Desde KumbiaPHP queremos dar un agradecimiento especial al amigo Hector Rodriguez (acá Al3jandro) por su valiosa colaboración en la organización del evento y encontrar los espacios que dispondremos para esa fecha.

Fuente… KumbiaPHP

Bien lo cierto es que cuando se corrió el benchmark los #request/seg no cuadraban y no era lógico ya que la nueva estructura se depuraron ciertas cosas que sobraban, en el benchmark los números obtenidos eran tan locos que la vieja estructura tenia unos 10 #req/seg por encima :-S no era nada normal esto, nos toco recurrir a las buenas prácticas de desarrollo y que ya es una constante dentro del Equipo de Desarrollo de kumbiaphp hacer debug y profiler con xdebug :-), esto para detectar donde estaban los “cuellos de botellas” que nos hacían mas lento que la versión anterior.

El detalle estaba en una función de PHP llamada extract, dentro de kumbiaphp framework se utiliza esta dicha función en el core ya que el framework implementa las variables de instancia (algo muy parecido de Rails), es decir todo lo que llame en mi controlador $this->var o sean atributos públicos, en la vista los tengo disponible como $var, volviendo al punto esta funcion nos permite hacer lo antes dicho pero recibe ciertos parámetros uno es unas constantes entre ellas EXTR_OVERWRITE (Si hay colisión, sobrescribe la variable existente) nosotros decidimos sacar la constante porque en la documentación Oficial de PHP dice claro lo siguiente:

Si no se especifica tipo_extraccion , se asume que vale EXTR_OVERWRITE.

Bien como sabemos el xdebug nos da mucha información y la misma nos decía que el “cuello de botella” estaba allí ya que tomamos un profiler de la versión anterior y los tiempos eran totalmente distintos en ese punto. viendo en detalle la función extract decidí olvidar lo que dice el manual de PHP y pasar de forma implícita el tipo de extracción en este caso EXTR_OVERWRITE, una vez hecho el cambio vuelvo a correr el benchmark y como por arte de magia ahora obtengo los resultados esperados la nueva estructura ha causado efecto en velocidad y esta ~10 #req/seg por encima respecto a la vieja estructura.

Conclusión.

Tal como dice el titulo del post no hay que confiarse de lo que dicen algunos manual, ya que pueden ocurrir excepciones como la que comente aqui. En el caso descrito fue detectado este detalle porque se hizo uso de las buenas prácticas de desarrollo y de las herramientas disponibles y el turno fue para una que muchos obvian (xdebug), que si le damos el uso correcto podemos ganar mucho en nuestros desarrollos.