Due to the introduction of a new menu system in CiviCRM 2.1, my summer project got one more item on its list – the localisation of the menu entries.
Until now, all of the localisable strings in CiviCRM were enclosed either in the PHP’s ts(…) function calls or in Smarty’s {ts}…{/ts} blocks. This approach was most convinient: first – the function/block call was short to type (and did not introduce a lot of noise into the code); second – making sure CiviCRM is internationalised for translation (i.e., all of its strings are localisable) was as easy as looking through the code/templates and wrapping the visible strings in the above calls; third – once we’ve written a simple PHP/Smarty parser, creating the POT files for translators’ use was simple: just scan the code and the templates and pull out anything that’s inside those calls.
This approach worked quite ok until the new menu system appeared on the scene; from CiviCRM 2.1 on, the entries in the menu are not defined in the code, but instead in the database (in the civicrm_menu table), which itself is generated from a set of XML files.
Fortunately, after some digging around I found out that the two methods that create the final structure for menu and page title display – CRM_Core_Menu::get() and getNaviation() – happen to keep the translatable strings in array fields keyed with title, so a method localising them in place and a new POT file with the menu structure (in the future, generated automatically from the abovementioned XML files) was all that was needed to make the menu localised to the currently selected language.
