[wp-trac] Re: [WordPress Trac] #3047: get_plugininfo()
WordPress Trac
wp-trac at lists.automattic.com
Mon May 7 09:17:00 GMT 2007
#3047: get_plugininfo()
------------------------------------+---------------------------------------
Reporter: forceagainstsomething | Owner: westi
Type: enhancement | Status: assigned
Priority: normal | Milestone: 2.3
Component: Administration | Version: 2.1
Severity: normal | Resolution:
Keywords: has-patch dev-feedback |
------------------------------------+---------------------------------------
Comment (by _erik_):
> I mean, you can't beat _e() or __().
ehm... i dont wanna beat _e() or __() but if a plugininfo-function exists,
it should _also_ tell/know the name of a plugins textdomain. ('''as i said
before''') Seems you just got me wrong. When saying 'simplify l10n', i
didn't mean the function names. maybe a code example makes it more easy to
understand for everybody...
this is the syntax proposed:
{{{_e('translate this!', 'wordpress-has-no-idea-what-exact-textdomain-a
-plugin-uses');}}}
(even though that it also works without the textdomain - thats the way
most people write it down...) it seems convenient to me to let a general
get_plugininfo()-function acess this string, too. so one won't have to
repeat '''the name of the textdomain''' over and over again...
currently one will have to add the $path to the call of the textdomain
function in a plugin which could be done in the function itself (if it
only knew the textdomain/filename for the plugins .mo. it could search
where it is stored eg: plugins/ or /plugins/myplugin/ or
/plugins/myplugin/subdir/)
most important argument to me would be that this would allow l10n of all
plugins uploaded. (eg: descriptions) without actually having the plugin
activated or using it
--
Ticket URL: <http://trac.wordpress.org/ticket/3047#comment:26>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list