Hi Micha,
Am 14.03.2010 17:47, schrieb Michal Čihař:
Hi
Dne Sat, 13 Mar 2010 16:00:13 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
I've seen the file /libaries/messages.inc.php. Would this the final solution?
No, the messages should be used directly in code/templates, this is just for the easy transition, because this way we can use gettext without really changing most of the code. I plan to move messages slowly from messages.inc.php to places where they belong, but it is nothing high priority.
Okay ... perhabs with templating I must do this if we don't want use the $strNameWhatElseEver in future releases.
If yes, I can use in template engine things like $strXxxXxx, Else if not, I will write a filter function for TWIG-templating, but I think it would be overheaded.
It looks to me strange that there is not a templating system for PHP which support localization natively.
Yes your right. Many template designers uses for each language a languag file (as we done), or - that's a really terrible way - for each langage an own skin (roll eyes). Internationalization is not a proiority by templete engines, but by the way Dwoo (alternative to Smarty, but for PHP 5 and faster) has this functional, and in Twig I must write my own filter. If we want switch later to Symfony framework, we can use Dwoo or Twig as a plugin. For other frameworks (like Zend) only Dwoo has a ready to go plugin feature. Perhabs it would be better to use Dwoo instead of Twig?
Is it possible for you, to add a switch in your select lang library? If I need strings in Javascript, that I would be able to include such a thing like:
<script type="text/javascript" src="select_lang.php?js=selected_lang"></script>
This should me return javascript compatible strings as an object like var pmaStringJS = { strAbortedClients : 'Aborted', /* ... and so on */ 'strZip' : 'zipped' }
I really don't see single reason why it should be part of select_lang.php (especially as it is in libaries, which we suggest to protect from remote access).
Was only a sample. A own script would be good to ;)
But we can definitely create such code. Django has something what provides gettext like functionality to javascript, but I don't know if the code is enough generic so that it can be used in other project.
Django is python or I'm wrong?
The Problem: UTF8-Strings should be encoded with \uXXXX. Sample: 'Löschen' will become 'L\u00F6schen'.
There is some problem in using http headers for defining charset for javascript?
Yes, browser can ignore charset (by wrong encoding settings). This is a bulletproof solution. Many big JS-projects (like TinyMCE or jQuery) use the \uXXXX, cause only displayed text will be damaged, not the functional of a script. At the moment at the latest release all works fine with js, but when I switch to template base and jQuery perhabs I need new translated strings. That's the reason, why I started discussion.
Michael