Hi Micha,
Am 14.03.2010 17:47, schrieb Michal Čihař:
Hi
Dne Sat, 13 Mar 2010 16:00:13 +0100
Michael Keck <sfnet(a)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