module multilingual standard

[rallek]

There is a translatable flag inside modulestudio. If I use this do get for this field an input for each language. Typical fields are title ad description.

In News we see another idea. There you can select which language the current news should be. If you want to have more than one language you have to add a news for each language you want.

I do like the modulestudio way more.

I wonder what is the way for multilingual content in the future?

I would like to have the translation of the future implemented in https://github.com/cmfcmf/MediaModule/issues/33

[cmfcmf]

Things to consider: a) The database side - shall we use the Doctrine Extensions Translatable Extension or something different? b) The Symfony form side

[rallek]

@Kaik any idea from your side?

[craigh]

I think this is a 2.0 ticket.

[rallek]

if 1.4 do have a FC layer we should clarrify this in 1.4.2 time. There we might need some decisions for the future.

For me as a non native english speaker this is a fundamental topic.

[Kaik]

@rallek I have seen it, read some docs, but have not tried it yet.

[rallek]

@Kaik what do you want to try? I am interested in a concept. I would like the concept with translatable fields like given in modulestudio most. But there are other concepts possible as well. Which one should be the recommended for future zikula modules?

[craigh]

Frankly, I think this is not a core issue. The core doesn't need to impose on a module developer the way they would like to accomplish translatable fields. Personally, I have always liked the concept of Doctrine Extensions Translatable Extension but what if another developer feels differently? There is no reason and actually no way for the core to impose a restriction on this.

[cmfcmf]

The problem is that the core currently doesn't provide the full tools to do translatable fields with Symfony Forms. There is no easy way to integrate it with Symfony Forms right now.

[rallek]

And somewhere we do need documentation. When it is not core where than?

[Kaik]

Well, I was thinking about it some time ago and before have used "page per language" like @rallek mentioned. Doctrine has its own way to handle this. I have read about it but did not have time to play with it.

[rallek]

I think this is the document expaining how to proceed: https://github.com/Atlantic18/DoctrineExtensions/blob/master/doc/translatable.md Dificult to understand for me :-)

[rallek]

@Guite what is modulestudio going to offer in future? Will it stay as it is or will there be a change for future generated modules?

[Guite]

Actually ModuleStudio offers both ways:

1. You can use translatable fields. This is useful for content which needs to be available in multiple languages.
2. You can also add string fields and mark them as language to have a language selector. This is useful if you like to create content for a specific language and filter the list view for a certain language afterwards.

You can not simply tell which function is superior. It highly depends on your use case and how content creation should be structured. For example if different persons are responsible for different translations it is not that elegant to have all translations on one page. Instead one would rather like to have the translation process separated (like how Content does it).

I do not really understand your question. The functionality will be kept, there is no fundamental change plan. However, translatable support is going to be improved a bit like described here:

https://github.com/Guite/MostGenerator/issues/338 https://github.com/Guite/MostGenerator/issues/386 https://github.com/Guite/MostGenerator/issues/177

What is also potentially relevant for translatable fields is a language white list:

https://github.com/zikula/core/issues/2541

[rallek]

my discussion starts with @cmfcmf for the mediaModule in https://github.com/cmfcmf/MediaModule/issues/33. But at the end you are right. Both ways are valid. In my case I like translatable most.

The idea of the discussion was to have a kind of stile guide for new modules, a kind of best practice.

Let us close here

[cmfcmf]

I still want to keep this open as there currently is no functionality provided by the core to create translatable form fields.

b) The Symfony form side

It should at least be checked what is available and if it's worth including into the core.

[rallek]

As @craigh is hard-working changing the blocks module I want to know how Zikula is doing translation for core modules. This might be a typical example for other modules as well ;-)

Do we have a test for translation?

[craigh]

http://symfony.com/doc/current/book/translation.html#translating-database-content https://github.com/KnpLabs/DoctrineBehaviors https://github.com/Atlantic18/DoctrineExtensions

[craigh]

you know there are too many open and similar language/translation tickets when you cannot decide which one to log a comment in. I would welcome someone reviewing all open tickets in every milestone that are language/translation related. And recommending merging/closing those that are pseudo-duplicates. (@rallek maybe you could do this?)

Anyway - I ran across this interesting blog today. http://jolicode.com/blog/translation-workflow-with-symfony2

[craigh]

https://github.com/Happyr/TranslationBundle

[Guite]

I would welcome someone reviewing all open tickets in every milestone that are language/translation related. And recommending merging/closing those that are pseudo-duplicates. (@rallek maybe you could do this?)

:+1:

[Guite]

See https://github.com/zikula/core/labels/Language%2FTranslation

[rallek]

will do as much is possible right now. I am very very bussy unfortunately.

might be we can discus the language issue next week at the Camp Zikual 2016 ;-)

[rallek]

I did a short review. Some comments I have added but some tickets I do not understand enough. I will try to bring this topic on the agenda of the upcomming Camp Zikula.

[Portugao]

@Guite How to use this option?

You can also add string fields and mark them as language to have a language selector. This is useful if you like to create content for a specific language and filter the list view for a certain language afterwards.

[Guite]

Add a string field and activate the language option for it. Note there is also a locale option, too. Use the one which fits your need best. The list view filtering options are also pregenerated for language, locale, country (etc.) fields. The quick navigation form should include selectors for this already so you can check there how you need to assign the parameters to your urls.

[Kaik]

It might be needed to create bootstrap.php file in module root and add something similar for translatable

$helper = ServiceUtil::getService('doctrine_extensions');
$helper->getListener('timestampable');
$helper->getListener('softdeleteable');

I have no time to check what is working and what is not.

[Portugao]

Add a string field and activate the language option for it. Note there is also a locale option, too. Use the one which fits your need best.

I do not know both ways and their handling. What does a language field and a locale field do?

[rallek]

I have also more questions than answers around translations. Let us discus next weekend ;-)

[Guite]

What does a language field and a locale field do?

From the generator reference (which is worth reading by the way):

• language - A boolean specifying whether this field represents an Unicode language identifier or not. Possible example values are fr or zh-Hant.
• locale - A boolean to specify whether this field represents a locale or not. Possible example values are fr or _frFR.

Example for the difference: both United States and United Kingdom use English as language. But they have different date formats. So the locale refers to internationalisation, while language relates to translation.

[Guite]

Frankly, I think this is not a core issue.

I still want to keep this open as there currently is no functionality provided by the core to create translatable form fields.

There is http://a2lix.fr/bundles/translation-form/3.x.html

I suggest closing this (very general) discussion. If including such a tool into the core is desired this should be treated by another (more concrete) issue.