Opened 15 years ago
Closed 13 years ago
#13819 closed feature request (wontfix)
localization and TextDomain
Reported by: | bueltge | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | I18N | Keywords: | localization textdomain |
Focuses: | Cc: |
Description
wp-admin/includes/plugin.php
Function get_plugin_data()
It is possible to use the value TextDomain in the comments of a plugin to set a textdomain for lacalization. It's is not simple to use this value in the php-code, only with a own function, she parse this value from the plugin and give the value to a constant or var.
Also it is hard to write translations-files .po /.mo include the string on this comment. PoEdit or WP-plugin localization from Heiko Rabe cant read this string. Maybe it is possible to change this and parse in get_plugin_data()
for a string to the Value 'TextDomain' => 'Text Domain';
than it is possible to write the string in the default fucntions __()
or other and use poEdit or similar.
The same problem is the value Domain Path
. He is also a redundant value in the code of a plugin or the developer must parse his own comments on this section.
Change History (5)
#3
@
15 years ago
Actually it is not possible to scan the metadata with a tool to create the .po files. The text in metadata is not exisist for this tools. Also it is an redundant to set the text domain. Plugin-authors write the text domain and domain path in the meta data and also in the php-source of a plugin. Maybe it is better it give a function on the wp core to use the domain path and text domain insiede the php source.
- Sorry for this bad english, tired and hard for me.
#4
@
14 years ago
- Component changed from General to i18n
- Milestone changed from Awaiting Triage to Future Release
#5
@
13 years ago
- Milestone Future Release deleted
- Resolution set to wontfix
- Status changed from new to closed
We avoid doing this in the PHP source because then the headers of a deactivated plugin can still be translated. If a plugin author wants to use the domain in code, they should just duplicated it in code.
This is our tool for extracting these strings: http://i18n.svn.wordpress.org/tools/trunk/pot-ext-meta.php. I think that language packs will make Text Domain rather redundant.
I'm not entirely sure what you're suggesting, but it seems like this stems out of a misunderstanding of the L10n process. PHP is not used to process gettext into a POT file, so using a variable as the textdomain wouldn't work.