Make WordPress Core

Opened 14 years ago

Closed 12 years ago

#13819 closed feature request (wontfix)

localization and TextDomain

Reported by: bueltge's profile bueltge Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: I18N Keywords: localization textdomain
Focuses: Cc:



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)

#1 @nacin
14 years ago

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.

#2 @ocean90
14 years ago

  • Keywords changed from localization, textdomain to localization textdomain

Related #5651 #3089

#3 @Bueltge
14 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 @nacin
14 years ago

  • Component changed from General to i18n
  • Milestone changed from Awaiting Triage to Future Release

#5 @nacin
12 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: I think that language packs will make Text Domain rather redundant.

Note: See TracTickets for help on using tickets.