Description
Feature Request: Use __d() in plugin context during bake
Description
When using bake to generate code within a plugin using the -p (or --plugin) option, all translatable strings are currently generated with the __() function, regardless of the plugin context.
Example:
bin/cake bake all Posts -p MyPlugin
Generates code like:
__('Edit Post')
However, the recommended approach for translations inside plugins—as per CakePHP documentation—is to use __d('plugin_name', ...) with the plugin name as the translation domain. So the expected output should be:
__d('my_plugin', 'Edit Post')
Why this matters
It aligns with CakePHP’s i18n best practices.
It avoids the need to manually replace all __() calls with __d() after baking.
It improves plugin encapsulation by keeping translations scoped to the plugin.
Proposed behavior
When the -p or --plugin option is used with bake, the generated templates, controllers, and views should automatically use:
__d('{plugin_name}', 'Text')
Optional enhancement
Allow a new flag like --i18n-domain=plugin or --use-domain to make this behavior explicit and flexible.
Thanks for your consideration!
Description
Feature Request: Use
__d()in plugin context during bakeDescription
When using
baketo generate code within a plugin using the-p(or--plugin) option, all translatable strings are currently generated with the__()function, regardless of the plugin context.Example:
Generates code like:
__('Edit Post')
However, the recommended approach for translations inside plugins—as per CakePHP documentation—is to use __d('plugin_name', ...) with the plugin name as the translation domain. So the expected output should be:
__d('my_plugin', 'Edit Post')
Why this matters
It aligns with CakePHP’s i18n best practices.
It avoids the need to manually replace all __() calls with __d() after baking.
It improves plugin encapsulation by keeping translations scoped to the plugin.
Proposed behavior
When the -p or --plugin option is used with bake, the generated templates, controllers, and views should automatically use:
__d('{plugin_name}', 'Text')
Optional enhancement
Allow a new flag like --i18n-domain=plugin or --use-domain to make this behavior explicit and flexible.
Thanks for your consideration!