ZendSkeletonApplication translations

[EvanDotPro]

Hi all,

With the addition of the new i18n component, I decided to update the skeleton to make use of translations. I don't have a lot of experience with multi-lingual applications, so I'd appreciate any feedback from those of you who do. :)

https://github.com/zendframework/ZendSkeletonApplication/pull/85

Thanks!

---
Evan Coury, ZCE

http://blog.evan.pro/

[Marco Pivetta]

Awesome!
We could need a language switching feature, but introducing sessions in skeletons feels kinda weird...

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    

On 6 July 2012 06:24, Evan Coury <[hidden email]> wrote:

Hi all,

With the addition of the new i18n component, I decided to update the skeleton to make use of translations. I don't have a lot of experience with multi-lingual applications, so I'd appreciate any feedback from those of you who do. :)

https://github.com/zendframework/ZendSkeletonApplication/pull/85

Thanks!

---
Evan Coury, ZCE

http://blog.evan.pro/

[sasezaki]

Hi.

I'm wondering "Help&Support" paragraph should be NOT translated?
#zftalk.2 & ML is used English :-(
So this paragraph be better to encourage have annotation for locale's
community website links.

--
sasezaki
https://github.com/sasezaki

2012/7/6 Evan Coury <[hidden email]>:

> Hi all,
>
> With the addition of the new i18n component, I decided to update the
> skeleton to make use of translations. I don't have a lot of experience with
> multi-lingual applications, so I'd appreciate any feedback from those of you
> who do. :)
>
> https://github.com/zendframework/ZendSkeletonApplication/pull/85
>
> Thanks!
>
> ---
> Evan Coury, ZCE
> http://blog.evan.pro/
>

[HHGAG]

Hi,

something like that should be ok for the skeleton:

https://github.com/zendframework/ZendSkeletonApplication/pull/85/files#r1111308

Perhaps additionally an extension for a Get parameter


On Fri, 6 Jul 2012 10:02:14 +0200, Marco Pivetta <[hidden email]>
wrote:

> Awesome!
> We could need a language switching feature, but introducing sessions in
> skeletons feels kinda weird...
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://marco-pivetta.com
>
>
>
> On 6 July 2012 06:24, Evan Coury <[hidden email]> wrote:
>
>> Hi all,
>>
>> With the addition of the new i18n component, I decided to update the
>> skeleton to make use of translations. I don't have a lot of experience
>> with
>> multi-lingual applications, so I'd appreciate any feedback from those of
>> you who do. :)
>>
>> https://github.com/zendframework/ZendSkeletonApplication/pull/85
>>
>> Thanks!
>>
>> ---
>> *Evan Coury, ZCE*
>> http://blog.evan.pro/
>>
>>

--
Hasan H. Gürsoy (HHGAG)

[EvanDotPro]

First of all, thank you very much to everyone who's already contributed translations! I opened the PR just a few hours ago and already we have German, French, Japaense, Turkish, and Czech!

Second, is the question of language switching... see the comments on the PR here:

https://github.com/zendframework/ZendSkeletonApplication/pull/85#discussion_r1111231

Also raised was the question of naming the directory 'locale' instead of 'language':

https://github.com/zendframework/ZendSkeletonApplication/pull/85#discussion_r1111334

Any feedback or input would be greatly appreciated!

---
Evan Coury, ZCE

http://blog.evan.pro/

[EvanDotPro]

On Fri, Jul 6, 2012 at 3:56 AM, "Hasan H. Gürsoy" <[hidden email]> wrote:

Hi,

something like that should be ok for the skeleton:

https://github.com/zendframework/ZendSkeletonApplication/pull/85/files#r1111308

Perhaps additionally an extension for a Get parameter

As mentioned on Github, perhaps we could check class_exists for Locale, before trying this to help ease the hard dependency on the intl extension if we go this route.

[dlu-gs]

EvanDotPro wrote

With the addition of the new i18n component, I decided to update the
skeleton to make use of translations. I don't have a lot of experience with
multi-lingual applications, so I'd appreciate any feedback from those of
you who do. :)
https://github.com/zendframework/ZendSkeletonApplication/pull/85

Hi,

is the translator instance configured via the 'translator' configuration key meant to be application wide (i.e. a single translator for the whole app)? The configuration approach (and the TranslatorServiceFactory) suggests so. How should the translator configuration look like when more than one module with translations is used? I presume the translations should be kept with the corresponding module, but the translations for the same locale from different modules overwrite each other en bloc instead of adding and selectively overwriting only the same msgids (please see Translator::loadMessages()).

As for the folder name - it contains translations, so I think it should be named 'translation', but 'language' is also fine. I do not like the name 'locale' much, as the folder really does not contain any locales (just translations named by locales, which is something different). But let's not get too involved here, or we are risking the bike shedding :)

Thanks,
David

[HHGAG]

Hi David,

one translator instance is used for all modules, you can add translations like

    'translator' => array(
        'translation_patterns' => array(
            array(
                'type'     => 'gettext',
                'base_dir' => __DIR__ . '/../language',
                'pattern'  => '%s.mo',
                'text_domain' => 'accesskey-box'
            ),
        ),
    ),

over module.config.php from each module. If you use text_domain you can seperate them from other modules otherwise the text_domain would be "default" so it could be, that translations will be overwritten (i haven't proved it yet)

[dlu-gs]

Hi Hasan,
that's exactly what I did (except for the text_domain) and the translations got overwritten. Protecting the translations with a unique text_domain doesn't seem right:
   
   1. it would violate the ZF2 modularity principle - you cannot foresee which other modules will end up in an application together with your module and thus you cannot be sure if they do not use the same text_domain for their translations
   
   2. you would have to specify the text_domain with every call to the translate() view helper (smells bad)

Anyway if there is supposed to be only one translator instance I would expect it to collect translations from all modules, not just the last one. Maybe it should be done in some other way.

[HHGAG]

We use the CamelCaseToDash'ed Namespace for the text_domain. Our templates use the text_domain's at the moment, but that will be end in a helper.

I think text_domain isn't bad, it could be automatized with an canonical name like namespace/modulename as text_domain if shared translations aren't wished.