Support for Full Blog Translation

[harkos]

I have spent the last week working between two WP translation plugins to get them working together and extend their funcionalities. From this work, I learned that in order to translate every bit of desired text, a few changes had to be made, specially access to other parts where there were no filters.

So, I added the following filters:

• translate (called from __l())
• wp_get_archives (called from wp_get_archives())
• before_sanitize_title (called from sanitize_title())

And the following functions:

• __l()
• __le()

Mostly, they speak for themselves, but all have important roles to allow the creation of fully multilanguage themes and blogs. I hope this helps many people like me.

[harkos]

Changes to sanitize_title()

[harkos]

Adds l() and le()

[harkos]

Changes to wp_get_archives()

[majelbstoat]

We don't need _l(), we already have (). We don't _le(), we already have _e(). A before_sanitize_title filter, we don't really need either - you can change the title before sanitising in other places. FYI, there are already plugins out there that can localise all content without these new changes you propose - look at wp-multilingual.net and change the language to Deutsch for an example. (The theme content there that isn't translated is because a translation hasn't been written yet, not because the plugin can't do it).

With the greatest respect, I think you need to spend a little more time with the codebase before opening tickets requesting changes. This is the third invalid one in a short space of time.

[majelbstoat]

And if a trac admin could put those functions in code blocks, I'd be grateful. Wikiformatting always gets me...

[harkos]

I apologise for openning so many tickets but you could provide a few more useful information than "we don't need it". You don't need it, but how about others? If we don't need these enhancements, than how could one, for example, handle the very same title before sanitizing? How will _() and e() handle custom work from plugins? You should encourage others to explore such a great tool instead of talking in a way that will mostly make people angry about you and discount on the tool.

[harkos]

And the solutions pointed at wp-multilingual.net don't work out fine as I expected. Good reason for starting over, uh?

[majelbstoat]

Apologies if I wasn't clear enough:

We don't need

_l()

because we already have the function

__()

which does exactly the same job using gettext. There is no need for a translate filter when there is already a standard way of translating everything in this manner. If you desperately needed a function to translate one string to another defined outside of a .po or .mo file, include those functions in your plugin. Likewise for

_le()

there is the equivalent

_e()

. Have you looked at using those functions and found a particular problem with them? Instead of before_sanitize, use title_save_pre. Try ​http://wphooks.flatearth.org/hooks/ for a full list of available hooks, as well as a WordPress X-Ref. Again, sorry if my reply was a bit terse, but I still think this is invalid. But this time, I'll leave it for dev feedback...

And, on a personal note, I'd be interested to know what exactly doesn't satisfy you about the translations at wp-multilingual.net - if you can spare the time, drop me a note, using the contact form at jamietalbot.com.

Cheers,

Jamie.

[harkos]

Thanks for this reply. Let's see if I can do the WikiFormatting right this time. Indeed I went looking for __() and __e() and found an even better filter: locale. I don't remember it being part of the documentation on wordpress.org. I'll try that out, as it might reduce my work.

As for the filter, my need falls somewhere between title_save_pre and name_save_pre, but they are still not good enough, unless I'm able to set $post_name from a filter applied to title_save_pre.

How about the changes I proposed to general-template.php? Is there another way to get those dates and change them? I might work it out differently if my try with locale filter works out, but I need a fallback.

[nbachiyski]

On line 364 in general-template.php lies the following:

$text = sprintf(__('%1$s %2$d'), $wp_locale->get_month($arcresult->month), $arcresult->year);

Here, every language can define its own structure for the text. At this stage a translator just cannot know what this string is about, however we have made some firm steps in that direction and soon we will be able to add descriptions for gettext strings. Anyway, let me not digress much :)

The text for the yearly archive is unconditionally '%d' % year, and the daily and weekly archives are locale-aware.

There certainly is place for i18n improvement in this function. However I do not think it will be convenient for most of the translators if we just used hooks and they were left with no real chance for translating the string. In my opinion we should aim to gather everything around the gettext strings idea.

P.S. 3 simple tricks to get with the formatting here: preview, preview, preview :)

[harkos]

The locale stuff I was talking about, it worked! Even for dates themes get from the_time() and the_date(), but the archives string still doesn't work.

About adding or not a filter, I think it opens for some plugins work special events. For example, lets say I'm a sotware developer. I could have a plugin to change style of an archive entry so it's shown different when I set a special post announcing a new version of my product. I think the filter might come in hand.

And sorry, I didn't get the "preview" hint...

[harkos]

Sorry again, I forgot to mention, the month didn't get translated on the archives list, even working with the_date() and the_time().

[nbachiyski]

the_date and the_time work perfectly for me. They both use internally mysql2date, which respects wp_locale.

P.S. The preview hint was aimed at Jamie.

[harkos]

It worked now. Just needed to disable the work I was doing with my mess up with general-template.php. Now there is only the sanitize stuff missing...

[harkos]

Anyone there?

[majelbstoat]

This ticket is marked with dev-feedback, so we'll have to wait and see what one of them says... I suppose before_sanitize might be useful if you wanted a sanitized slug that was different from the title of the post, but still somehow related to it... That said, you probably could do it a different way, hooking edit_post and save_post.

On a side note, have you joined the wp-hackers mailing list? There are lots of people there who are willing to give help on developing plugins and you can discuss whether something is necessary before opening a ticket. You'll find that many of the things you want to do are already possible.

[harkos]

Currently, I tested the plugin and every other problem I had was solved. So it's fine and I'm only waiting for this sanitize problem to be decided. Is it possible to change the value for $post_name on a call function called to filter title_save_pre? That would solve the problem as well.

[harkos]

I have found another problem: when someone wants to list a post by ID (like listing the 5 most recent posts), there seems to be no way to process the page title. Shouldn't it be a good reason for another filter?

[darkdragon]

No traction in a while. Seems like the issues are solvable with __() and _e(), so closing and won't fix, unless developer feedback is done.