I18n with Yii

Curious about Yii, I wanted to test its I18n features.

The documentation on the web site is a good starting point, but some hints are missing, and I had to google a bit to find out.

You can see which language is currently set by accessing the value of Yii::app()->language.

If needed, you can also change the value, for instance to view a string in different languages. For instance, this code in a view:

<?php foreach(array('en', 'it', 'pl') as $lang): ?>
  <?php Yii::app()->language=$lang ? ?>
  <p><?php echo $lang ? ?>:
  <?php echo Yii::t('App', 'Internationalization experiments') ? ?></p ?>
<?php endforeach ?>

would produce something like:

en: Internationalization experiments
it: Esperimenti con l'internazionalizzazione
pl: Eksperymenty z internacjonalizacją

Yii has a good and "natural" support for language plural rules. This is something everybody programming should take care of. For instance, see how easy it is to manage different plural forms for Polish:

<?php Yii::app()->language='pl' ?>  
 <ul>  
 <?php for($i=0; $i<=30; $i++): ?>  
 <li><?php echo Yii::t('App', '{n} file|{n} files', $i); ?></li>  
 <?php endfor ?>  
 </ul>  

To write a translation string like jeden plik|{n} pliki|{n} plików is enough to obtain

• 0 plików
• jeden plik
• 2 pliki
• 3 pliki
• 4 pliki
• 5 plików
• 6 plików
• ...
• 10 plików
• 11 plików
• 12 plików
• ...
• 21 plików
• 22 pliki
• 23 pliki
• 24 pliki
• 25 plików
• 26 plików
• ...

Last but not least, if you want to access preferences set in the user's browser, you can follow the excellent example in Rethrown Exception.

Rimuovere i byte BOM dal codice sorgente

È un classico problema che ci si può trovare ad affrontare maneggiando codice sorgente di applicazioni, costituito per lo più da semplici file di testo. Si tratta dei byte del cosiddetto BOM, aggiunti a volte dagli editor all'inizio dei file Unicode per contraddistinguere il tipo di codifica utilizzata (UTF-32, UTF-16, UTF-8).

Un editor esadecimale, o anche più semplicemente il programma od, sono in grado di mostrarci i byte inseriti. Prendiamo ad esempio un file che inizia così:

  /* questo è il punto di avvio dell'applicazione

   */


  require_once('config.php');  // inclusione del file di configurazione
  require_once('functions/generic_functions.php');  // inclusione...

Se con od diamo un'occhiata, ci rendiamo conto dei caratteri inseriti nelle prime posizioni:

$ od -a index.php | head
0000000   o   ;   ?   <   ?   p   h   p  cr  nl  cr  nl  sp  sp   /   *
0000020  sp   q   u   e   s   t   o  sp   C   (  sp   i   l  sp   p   u
0000040   n   t   o  sp   d   i  sp   a   v   v   i   o  sp   d   e   l
0000060   l   '   a   p   p   l   i   c   a   z   i   o   n   e  cr  nl
0000100  sp  sp  sp   *   /  cr  nl  cr  nl  sp  sp   r   e   q   u   i
0000120   r   e   _   o   n   c   e   (   '   c   o   n   f   i   g   .
0000140   p   h   p   '   )   ;  sp  sp   /   /  sp   i   n   c   l   u
0000160   s   i   o   n   e  sp   d   e   l  sp   f   i   l   e  sp   d
0000200   i  sp   c   o   n   f   i   g   u   r   a   z   i   o   n   e
0000220  cr  nl  sp  sp   r   e   q   u   i   r   e   _   o   n   c   e

Il file dovrebbe invece iniziare direttamente con il simbolo <, come qui:

$ od -a index.php | head
0000000   <   ?   p   h   p  cr  nl  cr  nl  sp  sp   /   *  sp   q   u
0000020   e   s   t   o  sp   C   (  sp   i   l  sp   p   u   n   t   o
0000040  sp   d   i  sp   a   v   v   i   o  sp   d   e   l   l   '   a
0000060   p   p   l   i   c   a   z   i   o   n   e  cr  nl  sp  sp  sp
0000100   *   /  cr  nl  cr  nl  sp  sp   r   e   q   u   i   r   e   _
0000120   o   n   c   e   (   '   c   o   n   f   i   g   .   p   h   p
0000140   '   )   ;  sp  sp   /   /  sp   i   n   c   l   u   s   i   o
0000160   n   e  sp   d   e   l  sp   f   i   l   e  sp   d   i  sp   c
0000200   o   n   f   i   g   u   r   a   z   i   o   n   e  cr  nl  sp
0000220  sp   r   e   q   u   i   r   e   _   o   n   c   e   (   '   f

Fortunatamente, possiamo facilmente cercare i file "incriminati" per sistemarli, se ne abbiamo bisogno.

Una pagina di stackoverflow abbonda di suggerimenti al riguardo: elegant-way-to-search-for-utf-8-files-with-bom.

Su LinuxAsk si trova poi il suggerimento più carino su come ottenere tutti i byte a partire dal quarto:

tail --bytes=+4 text.txt

Seconda o terza persona per la descrizione delle funzioni?

Quando si scrive la descrizione di una funzione, a fini di documentazione, si deve indicare cosa essa fa e, in genere, che valore restituisce.

Ad esempio:

 /**
   * Returns the number of pixels in the picture.
      * @return integer the number of pixels in the picture
   */
   public function getPixels()
   {
     return $this->width * $this->height;
   }

La prima riga deve essere in seconda persona (imperativo) o in terza (indicativo presente)? La domanda sorge spontanea, visto che ci sono diverse abitudini, e diverse raccomandazioni. Vedi ad esempiohttp://drupal.org/node/487802#comment-1720946dove si trova questo "studio":

I like As If's explanation in #27. This got me thinking... Coding standards are always so personal -- there are choices in the Drupal standards (and standards at companies I've worked for in the past) that I don't like, but that I recognize as valid choices that simply differ from the style choices I prefer.
So, different people can have different valid opinions on whether function 1-line headers should be 2nd or 3rd person, and today I specifically looked, via web search, for doc standards that mentioned second person, and found one: Python http://www.python.org/dev/peps/pep-0257/ I found many more projects that prescribe 3rd person for doc header one-liners, besides the two I mentioned in my original issue report, but there is at least one thoughtful example of 2nd person being the standard.
I also thought it would be interesting to see what existing doc sets are actually using (independent of whether they have standards) -- both open-source and proprietary. Summary: They are all over the map. Here are some examples:
* The Java API uses 3rd person fairly consistently, although if you poke around, you can find 2nd-person instances: http://java.sun.com/javase/6/docs/api/
* Perl doc is all over the map, and some function doc lines don't even start with a verb (they don't have standards that I could find, and it shows): http://perldoc.perl.org/index-functions.html
* PHP doc uses 3rd person for some sets of functions http://us.php.net/manual/en/ref.filesystem.php, and 2nd person for others http://us.php.net/manual/en/book.strings.php (although there are some 3rd-persoOpzionin instances in this list, and their standard is 3rd-person)
* MySQL uses 2nd person: http://dev.mysql.com/doc/refman/5.4/en/string-functions.html
* Python is a mix: http://docs.python.org/3.0/library/math.html
* JQuery is a mix: http://docs.jquery.com/Traversing
* Microsoft's MFC classes seem to use mostly 3rd person: http://msdn.microsoft.com/en-us/library/3azzex5f(VS.80).aspx [note to self: don't use parens () in a URL, as Drupal's URL translator doesn't seem to recognize it when pasted in from the URL bar in my browser]
* Google Maps API uses 3rd person: http://code.google.com/apis/maps/documentation/reference.html
* Amazon EC2 API uses 3rd person: http://docs.amazonwebservices.com/AWSEC2/latest/APIReference/

Il problema sorge quando si usano diversi stili nello stesso contesto. Ad esempio, in symfony ci si accorge che l'imperativo e la terza persona singolare sono mescolati anche nella descrizione dei task standard:

plugin

  :add-channel    Add a new PEAR channel

  :install             Installs a plugin

propel

  :build               Generate code based on your schema

  :build-all          Generates Propel model and form classes, SQL and initializes the database

ma la terza persona è comunque prevalente. E a me piace di più (cosa fa la funzione? calcola questo e quello, restituisce il tal valore...).

Il web 2.0 in poche parole

Questo video è molto suggestivo, e illustra un sacco di concetti importanti in meno di cinque minuti: