Translating plugin's meta, was [wp-hackers] no-code-duplication i18n for WordPress

Thu Mar 6 15:44:37 GMT 2008

i'm seeing two problems with this:
1. if a server has fsockopen disabled, it might not work
2. this way for translation, you're forcing them to use the codex.
3. might create undue stress on the codex servers(or I guess they can handle
it)

On Thu, Mar 6, 2008 at 1:49 AM, Andrew Ozz <admin at laptoptips.ca> wrote:

> I would put it in the codex, but it's still just a proposal.
>
> Currently all plugins hosted on wordpress.org are required to have
> readme.txt, following specific formatting and are wrapped in a folder
> with the plugin's name when downloaded.
>
> It shouldn't be hard to auto-make a sub-directory named "languages" if
> it doesn't exist and add an empty .pot template named
> [plugin_name]_en.pot to it. The .pot would contain the meta strings,
> allowing them to be translated. It could even fill it with the current
> plugin's meta the same way it displays it on Extend - Plugins. I'll ask
> Mike about this.
>
> I was planning to go through older tickets this evening, as there are
> many that are fixed or invalidated by the changes in 2.5. But perhaps
> should start on a patch implementing this and see how it goes.
>
> Jacob Santos wrote:
> > This would be great on a Codex Page! Make sure to add a link from the
> > main Plugin Development page, so that people can find it. Also, a good
> > post like this will most likely be lost, so make sure to post back with
> > a link to the codex page.
> >
> >
> > Andrew Ozz wrote:
> >> IMHO the best and probably easiest way to do this is by standardizing
> >> the way plugins are written for WordPress:
> >>
> >> 1. Each plugin should be in a sub-directory of /wp-content/plugins.
> >> That way the plugins directory will be better organized and new users
> >> won't make the mistake of putting a plugin in the wrong sub-folder. I
> >> know there are many plugins that are installed directly in
> >> /wp-content/plugins, but what's wrong with putting them in a sub-dir
> >> if that would benefit new users? Also lots of plugins already follow
> >> this.
> >>
> >> 2. Each plugin should contain a directory named "languages" or similar
> >> with .pot and .mo files in it. The names of these files should be
> >> [plugin-name]_[locale].pot/mo and the first few lines of the .pot
> >> would be the plugin's meta. We can even provide a template for the
> .pot.
> >>
> >> It would be very easy to scan all .mo files when WordPress loads the
> >> plugin page and display the relevant language if it exists, or default
> >> to English if it doesn't. The average size of a plugin's .mo is just a
> >> few KB, so even if there are 40-50 plugins it won't take much memory
> >> or make the plugins page noticeable slower.
> >>
> >> Of course all this won't happen overnight, and the current display of
> >> plugin's meta would have to be supported for a while, or perhaps we
> >> can keep it as a default in case the plugin is not translated, but the
> >> sooner something like this is implemented, the better.
> >>
> >> Jacob Santos wrote:
> >>> Well, I think this part of the discussion has been beaten to death
> >>> (quite
> >>> literally actually).
> >>>
> >>> 1. There is already a solution to the problem in Trac, which was
> >>> create by
> >>> Jennifer and me. I think it is quite excellent, but why don't you
> >>> test it
> >>> to see?
> >>>
> >>> 2. The solution hasn't been accepted, because one that hasn't been
> >>> created
> >>> yet (although, honestly Ryan or a member of the core team or community
> >>> member might have already started on it) was just that.
> >>>
> >>> The central argument is whether to include the current solution, which
> >>> works and then obsolete it when the proposed better one comes along
> >>> or not
> >>> include the finished solution and wait until the proposed solution is
> >>> created, tested, has test cases, and is included in core.
> >>>
> >>> Unless you have thoughts on either the first point, or the second,
> >>> then I
> >>> think we'll go around in cycles beating the same issue to death once
> >>> again.
> >>>
> >>> You will find that both solutions are excellent (well, the first is
> >>> in my
> >>> opinion and I also love the second).
> >>>
> >>> I think that unless you have solutions to the metadata, the one that
> is
> >>> proposed, that the discussion is rather pointless.
> >>>
> >>> I would rather see input on how the other issues that haven't already
> >>> been
> >>> beaten to death or solved. I think it is rather interesting to see
> what
> >>> people come up with. I've yet to fully read the entire proposal for
> >>> i18n,
> >>> but I'll probably get around to it tonight.
> >>>
> >>>
> >>>> Anirudh Sanjeev wrote:
> >>>>> okay then how about this:
> >>>>> A seperate description text file for each language, in a seperate
> >>>>> directory,
> >>>>> or along with the .po files. All it's gonna be is desc-fr.txt or
> >>>>> desc-it.txtand wordpress can detect this along with the appropriate
> >>>>> textdomain and
> >>>>> install them. This way the issues with size and translation are
> >>>>> solved.
> >>>>>
> >>>> the idea was to avoid creating several files (there was an older
> >>>> proposal to add a file called metadata.php which would contain, well,
> >>>> the metadata, so wordpress would not need to load the whole plugin
> for
> >>>> that); some people seem to have the strange habit of putting all
> their
> >>>> plugin data and the kitchen sink into one file (php, html,
> >>>> javascript, I
> >>>> have yet to see base64-encoded images, but I wouldn't be very
> surprised
> >>>> to see it one day).
> >>>>
> >>>> I, for one, am for something like:
> >>>>
> >>>> can has metadata.php?
> >>>>     yarly
> >>>>         include metadata.php
> >>>>     nowai
> >>>>         parse teh plugin teh old way
> >>>>     kthx
> >>>>
> >>>> since a separate file would be overkill for small plugins
> >>>>
> >>>>> Also the major problem with adding them in the PO file is that the
> >>>>> localization file is loaded only when the plugin is activated or
> >>>>> load_plugin_textdomain is called
> >>>>>
> >>>> that's why metadata.php is a better idea: it could also
> >>>> load_plugin_textdomain if needed ;o)
> >>>>
> >>>> _______________________________________________
> >>>> wp-hackers mailing list
> >>>> wp-hackers at lists.automattic.com
> >>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
> >>>>
> >>>
> >>>
> >> _______________________________________________
> >> wp-hackers mailing list
> >> wp-hackers at lists.automattic.com
> >> http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
> >
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

-- 
Anirudh Sanjeev
Third Year Undergraduate Student, Indian Institute of Technology, Kharagpur
http://anirudhsanjeev.org
Mail: anirudh at anirudhsanjeev.org
Phone: +91-97335-04828
jabber/googletalk: anirudh at anirudhsanjeev.org
If this message is signed with PGP, you can verify with my public key at
http://anirudhsanjeev.org/pubkey.txt