3

I'm using a2lix_translation_form tabs in my form. It has the feature, that it allows you to edit several translations to one property in one form. I have it configured like this:

a2lix_translation_form:
    locales: [sk, en, de]       # [1]
    default_required: false ... # further as default

In the form I have following 3 Tabs where I can edit one property (Description)

|SK [Default] | En | DE |

It worked fine (stored things in database and so on), until I turned on the translatable in stof_doctrine_extensions. Here is the config:

stof_doctrine_extensions:
default_locale: sk
orm:
    default:
        translatable: true # not needed: listeners are not enabled by default

I also use jms_i18n_routing:

jms_i18n_routing:
    default_locale: sk
    locales: [sk, de, en]
    strategy: prefix_except_default

When I acess

localhost/app_dev.php/product/1/edit

then everything looks fine, but when I access

localhost/en/app_dev.php/en/company/11/edit

the Sk [Default] contains En description.

When I set the translatable in stof_doctrine_extensions to false the form is displayed correctly. But I need to have it ON, because I need it for other components. What can I do?

Andrej Sramko
  • 833
  • 7
  • 18

1 Answers1

1

You are in a specific case, that I don't advice henceforth. You will have some difficulties with you database if you change your default locale in the future.

I've updated the doc (I have still some work..), see the end of http://a2lix.fr/bundles/translation-form/#bundle-advanced. You can use annotation as explaned in the doc or add at the beginning of yours edit/create methods:

   $translatableListener = $this->get('stof_doctrine_extensions.listener.translatable');
   $translatableListener->setTranslatableLocale($translatableListener->getDefaultLocale());
webda2l
  • 6,686
  • 2
  • 26
  • 28
  • thanks! it works, but not exactly, how I imagined. I explain. I have a Product, which has a description and a category. User needs to be able to add a description in multiple languages, but the category (which is a separate entity) is selected from a dropdownbox, which should have translated labels, so the user would see the label in the current locale. What is the best approach to implement such form? In the solution I had before weere the categories translated. Is there a solution without default locale? Is there maybe another translation bundle more suitable to solve this than gedmo? – Andrej Sramko Aug 12 '13 at 05:56
  • I'm not sure to fully understand your question. It will be better to write a new question with details. If you have translated your categories on the same way that ProductTranslation, this snippet should show your categories in the same locale than the current locale. Unless you talk about the locale clicked from tabs ? – webda2l Aug 12 '13 at 10:04
  • ok, i will write new question bit later. But a quick explanation. I want to edit the Product's description in all 3 languages using translation form (i.e. ignoring currently selected locale), and at the same time select Product's category from a dropdown, which is translated into currently selected locale (picked up from CategoryTranslation)... what I achieved by your suggestion was that this dropdown has been in "default language" only – Andrej Sramko Aug 12 '13 at 11:04
  • You're right. You can forget this snippet and use the persist_default_translation option of the Gedmo strategy (see https://github.com/a2lix/TranslationFormBundle/issues/36#issuecomment-18202997). Or switch to another strategy (http://a2lix.fr/bundles/translation-form/#bundle-requirement). I plan to write blog posts about each soon. Note that in all this cases, you will have to re-enter translations about the default locale. – webda2l Aug 12 '13 at 11:22
  • thanks the **persist_default_translation** helped. Is it really worth to switch from Gedmo translatable to KnpLabs translatable? I didn't find any comparisons and Gedmo works quite ok for me. What is the advantage of KnpLabs? – Andrej Sramko Aug 12 '13 at 19:49
  • With Gedmo, if you look the SQL query, you will see that you have one JOIN relation for each translation field. When you have a lot of translations fields, it can become a problem. With IndexBy solution by KnpLabs or mine, you have only one JOIN relation for all translations. – webda2l Aug 13 '13 at 09:36
  • I figured out that persist_default_translation doesn't work that well. my default locale is "sk". when I'm displaying the site in "en" and create a new entry, db stores "sk" translation into the original table and into translations' table too. however, when I edit the "sk" translation afterwards, the change is done in translations' table only and thus not changing the original table. if I create new entry with locale set to "sk" it doesn't save the default translation into the original table at all (it leaves there "null"). Any ideas? – Andrej Sramko Oct 07 '13 at 06:37