Recent change (#1112500: Set proper default value for translation plugin) changed the default translation method for sites without locale.module enabled to 'none' from 'core'. The problem is when I went to export a default view for a module, it no longer included the $translatables array - which is a problem since those strings will no longer be available for localize.drupal.org to translate.

Not sure why we can't just keep 'core' as the default since this seems to cause more problems.

Comments

dave reid’s picture

Another view I just exported fails to output $translatables at all even though I have the translation plugin set to 'core'.

dave reid’s picture

Hrm, and now that view does. There seems to be non-consistent behavior with exporting $translatables.

dawehner’s picture

You know there is always a kind of problem beside end users and module developers.

If you have enabled the core mechanism it should add this to the output. Are you sure about that it doesn't?

Additional do you agree it makes sence to disable the method at the moment,
where there is no additional language available?

rszrama’s picture

Ahh! That's my problem. : P

So, I've been hesitant to update any of my default Views in Commerce because I noticed that the translatables array was no longer being includedi I heard it may be in the settings, but I could never find it because it was tucked away in the little Advanced tab. I rarely do any development in an installation of Drupal with Locale installed, so I've never incidentally seen the translatables again since they stopped appearing.

My recommendation would be exactly what Dave says - since Core is an option whether I have Locale enabled or not, why not just make it the default? Is there some drawback to exporting that translatables array that we should know about? I obviously want to ensure that all of our default Views are translatable. : )

dawehner’s picture

The question is whether you want to export the strings be default or not, what's the 80% use case here.

Adding a t() to a site without locale enabled is okay as nothing bad happens, so i would got to remove that special handling.

Alternative this could be enabled via drush views-dev