Make WordPress Core

Opened 11 years ago

Closed 10 years ago

#3976 closed enhancement (wontfix)

Support for Full Blog Translation

Reported by: harkos Owned by: harkos
Milestone: Priority: normal
Severity: normal Version: 2.1.2
Component: I18N Keywords: translation dev-feedback
Focuses: Cc:

Description (last modified by rob1n)

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.

Attachments (3)

formatting_php.patch (392 bytes) - added by harkos 11 years ago.
Changes to sanitize_title()
functions_php.patch (381 bytes) - added by harkos 11 years ago.
Adds l() and le()
general_template_php.patch (2.4 KB) - added by harkos 11 years ago.
Changes to wp_get_archives()

Download all attachments as: .zip

Change History (23)

11 years ago

Changes to sanitize_title()

11 years ago

Adds l() and le()

11 years ago

Changes to wp_get_archives()

#1 @harkos
11 years ago

  • Status changed from new to assigned

#2 @majelbstoat
11 years ago

  • Milestone 2.2 deleted
  • Resolution set to invalid
  • Status changed from assigned to closed

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.

#3 @majelbstoat
11 years ago

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

#4 @harkos
11 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

#5 @harkos
11 years ago

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

#6 @majelbstoat
11 years ago

  • Keywords dev-feedback added

Apologies if I wasn't clear enough:

We don't need


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


there is the equivalent


. 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.



#7 @harkos
11 years ago

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.

#8 @nbachiyski
11 years ago

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 :)

#9 @harkos
11 years ago

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...

#10 @harkos
11 years ago

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

#11 @nbachiyski
11 years ago

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.

#12 @harkos
11 years ago

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...

#13 @harkos
11 years ago

Anyone there?

#14 @majelbstoat
11 years ago

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.

#15 @harkos
11 years ago

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.

#16 @harkos
11 years ago

  • Milestone set to 2.2

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?

#17 @foolswisdom
11 years ago

  • Milestone changed from 2.2 to 2.4

#18 @rob1n
10 years ago

  • Description modified (diff)

#19 @darkdragon
10 years ago

  • Component changed from General to i18n

#20 @darkdragon
10 years ago

  • Milestone 2.5 deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

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.

Note: See TracTickets for help on using tickets.