Opened 18 years ago
Closed 17 years ago
#3976 closed enhancement (wontfix)
Support for Full Blog Translation
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 2.1.2 |
Component: | I18N | Keywords: | translation dev-feedback |
Focuses: | Cc: |
Description (last modified by )
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 fromwp_get_archives()
)before_sanitize_title
(called fromsanitize_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)
Change History (23)
#2
@
18 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
@
18 years ago
And if a trac admin could put those functions in code blocks, I'd be grateful. Wikiformatting always gets me...
#4
@
18 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
@
18 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
@
18 years ago
- Keywords dev-feedback added
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.
#7
@
18 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
@
18 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
@
18 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
@
18 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
@
18 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
@
18 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...
#14
@
18 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
@
18 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.
Changes to sanitize_title()