Hi,
Frank wrote:
> Hi,
> Looks like a good solution to me.
> The only possible problem (that may exist also with gettext) is with
> strings inside {literal} tags, I suppose they should be taken out of
> these tags or am I missing something?
Most likely we would just drop out of the literal tag for that string,
i.e. {/literal}{translate name="welcome_string"}{literal}.
Best Regards,
/bryan
> Frank
>
> Bryan Alsdorf wrote:
>
>> Hi,
>>
>> I decided to move this discussion to the eventum-devel list.
>>
>> Originally our plans were to use gettext and the smarty-gettext plugin
>> to localize Eventum. However, we would still need our own code to
>> handle longer strings (as discussed here:
>> http://lists.mysql.com/eventum-users/2735)
>>
>> The more I look at gettext, the more complicated it seems. I am now
>> leaning towards using a simpler method. Instead of PO files,
>> translated strings would be stored in PHP files, similar to this:
>>
>> == en_US ==
>> $_LANG['welcome_string'] = "Hello";
>>
>> == ru_RU ==
>> $_LANG['welcome_string'] = "Privet";
>>
>> The template files would use something like {translate
>> name="welcome_string"}
>>
>> With gettext, the file (with an extension of PO) would look like this:
>>
>> msgid "Hello"
>> msgstr "Privet"
>>
>> We would then have to run a program to translate the PO file to a
>> binary format that gettext uses (a MO file).
>>
>> The template file would look like {t}Hello{/t}.
>>
>> In my mind, the first solution seems much simpler to me. We don't need
>> to worry about gettext or having two translation sources (one for
>> normal strings, one for longer strings).
>>
>> Does anyone have any comments or opinions on this?
>>
>> Best Regards,
>
>
--
Bryan Alsdorf, Software Engineer
MySQL AB, www.mysql.com
Are you MySQL certified? www.mysql.com/certification
