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
Comment #1
dave reidAnother view I just exported fails to output $translatables at all even though I have the translation plugin set to 'core'.
Comment #2
dave reidHrm, and now that view does. There seems to be non-consistent behavior with exporting $translatables.
Comment #3
dawehnerYou 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?
Comment #4
rszrama commentedAhh! 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. : )
Comment #5
dawehnerThe 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