Month name declension

[waclawjacek]

Hey there,

Here's an excerpt from an e-mail I've sent to the wp-polyglots mailing list:

"I wanted to point out the fact that nouns in Polish have variants - it depends on the context you use them in. While I can make most of the strings fit the context and retain proper Polish syntax there's a problem with month names. Let me show you an example: "January" is "Styczeń" in Polish and that's all OK for the calendar
widget's header, but when it comes to "View posts for January 2008" it'd have to be "Zobacz wpisy opublikowane w *styczniu* 2008", same with "19 *stycznia* 2008" instead of "19 Styczeń 2008" (and unfortunately it's rather impossible to make a good looking workaround for all of them). It'd also be nice if translators could do the same with weekdays.

I guess the dates are fetched from PHP's date() so implementing such a feature would require some planning. It's not a serious issue, though the lack of it spoils the impression a bit. :)"

One idea is to use a switch() condition in combination with date() returning a numeric value which would be parsed by the aforementioned switch() returning the proper word.

[hakre]

Hi waclawjacek,

I am a little sad to say that such complex languages can not be properly displayed handled by WordPress. This is a known limitation, so nothing against the polish langauge.

This is the same thing for plural forms. Some languages have different plural forms for 2 and more items. Alls this can not be reflected with the current way of internationalization in wordpress.

[Denis-de-Bernardy]

Re-opening because I take it you're somewhat familiar with php and/or coding from knowing about the date() function. I take it there's a systematic rule to apply? Such as January 1st uses Styczeń and the other days use styczniu?

Anyway the mysql2date function (in wp-includes/function.php) gets called in various areas, but it seems to me that, adding an extra parameter along the lines of "apply a plural when a day greater than 1 is specified in the date", defaulting to a define, might do the trick.

WP could then store, internally, which languages apply, and define this accordingly depending on the language -- and things might end up working as you'd expect them to.

Please note that hakre, myself and most others here can at best suggest solutions on this one, from lack of understanding what should be returned. But most certainly there is a potential solution. Any odds you or a friend of yours are a coder who might be able to tackle it?

[waclawjacek]

Replying to Denis-de-Bernardy:

Re-opening because I take it you're somewhat familiar with php and/or coding from knowing about the date() function. I take it there's a systematic rule to apply? Such as January 1st uses Styczeń and the other days use styczniu?

Well, it's "styczeń" for every occurrence of the month name only and "stycznia" for "of January", such as "1st of January" ("1 stycznia").

[waclawjacek]

Oh, it's also "styczniu" for "in January" (forgot that WordPress also utilizes this one).

[Denis-de-Bernardy]

Ah... What a wonderfully complicated grammar. :-D

There is functionality in gettext to use one of two strings based whether it's a plural or singular, but I'm pretty certain that gettext won't manage that use-case correctly.

It's due to the fact that the strings are translated out of context and tossed "as is" into the result returned by php's date() function.

What *is* possible, however, is to programaticaly extract the context based on the original requested date format. The patch I'll upload in a sec will let you do just that.

You'd then need to write a plugin that catches whether a day is present in the requested format (see ​http://fr.php.net/manual/en/function.date.php), and that translates the resulting string as it should be.

[waclawjacek]

I've got a different idea on how to solve it. I'll try to bring it to life soon.

[waclawjacek]

I've got two other ideas on solving the issue, which of the former is, I believe, the most universal, though more messy. I think it's better to discuss them first.

• Separate strings for everything - allow the translators to translate month names wherever they appear (separate string for every month in every spot).
• Add an argument optionally passed to date_i18n() occurrences - every time a month name should be inflected - pass an argument telling the function which variant of a month name it should return (eg. the default being MONTH_NAME and the other two being OF (as in "of January") and IN (as in "in January")). Though it's probably neater, there is a serious drawback - feedback from other translators would be mandatory, because it's essential to know how many different cases there are in a language and some of them could be specific for just one language. That'd probably be a lot more complex and require way more planning.

[Denis-de-Bernardy]

• Separate strings for everything - allow the translators to translate month names wherever they appear (separate string for every month in every spot).

No no, I think you're not understanding. The underlying technology is GNU gettext. So WP is limited to that, and that only. Underneath, the January string used to localize the results of date() is a January string -- taken completely out of context.

• Add an argument optionally passed to date_i18n() occurrences - every time a month name should be inflected - pass an argument telling the function which variant of a month name it should return

That's pretty much what my plugin does. You scan for, say, d in the string, and if present you deduce it's something like 1st of January, and you override the thing accordingly using a plugin.

Adding an option to date_i18n probably isn't an option. Polish needs month, maybe another language needs the weekday, and maybe some other needs whatnot. With the filter I added, you can manage specifics for this or that language through the use of language-specific plugins, without cluttering the WP code base.

[Denis-de-Bernardy]

What my patch does, even. :-)

[waclawjacek]

Replying to Denis-de-Bernardy:

• Separate strings for everything - allow the translators to translate month names wherever they appear (separate string for every month in every spot).

No no, I think you're not understanding. The underlying technology is GNU gettext. So WP is limited to that, and that only. Underneath, the January string used to localize the results of date() is a January string -- taken completely out of context.

So gettext ignores duplicate occurrences of strings? I mean, let's say you allow the translators to translate "January" in one spot and then in another, would gettext ignore the latter and just use the translation of the former?

• Add an argument optionally passed to date_i18n() occurrences - every time a month name should be inflected - pass an argument telling the function which variant of a month name it should return

That's pretty much what my plugin does. You scan for, say, d in the string, and if present you deduce it's something like 1st of January, and you override the thing accordingly using a plugin.

Yeah, I just wanted to make a workaround without using plugins, because wouldn't it look kind of nasty to have a "Polish locale support etc. etc." plugin installed? It just seems to me that the only plugins a user should run should supply a site with additional features, not what they have to run in order for a WordPress component to work properly.

[Denis-de-Bernardy]

So gettext ignores duplicate occurrences of strings? I mean, let's say you allow the translators to translate "January" in one spot and then in another, would gettext ignore the latter and just use the translation of the former?

Haven't tried, but... either that, or it would cough an error (string defined).

Yeah, I just wanted to make a workaround without using plugins, because wouldn't it look kind of nasty to have a "Polish locale support etc. etc." plugin installed? It just seems to me that the only plugins a user should run should supply a site with additional features, not what they have to run in order for a WordPress component to work properly.

Agreed. Which is why I added 2nd-opinion. Maybe a core dev will show up and decide we also need a few lines somewhere to allow for this kind of localization "plugins" to be automatically loaded and centrally managed.

[ryan]

Alongside your pl.mo file you can provide a pl.php file that is automatically loaded. Some locales use this file to set text direction to RTL and support non-Gregorian calendars. You can do anything in it that a plugin can do.

[ryan]

(In [10897]) Add date_i18n filter. Props Denis-de-Bernardy. fixes #9396

[demetris]

Replying to ryan:

Alongside your pl.mo file you can provide a pl.php file that is automatically loaded. Some locales use this file to set text direction to RTL and support non-Gregorian calendars. You can do anything in it that a plugin can do.

A question and possibly a request:

Does this work for locations different than the theme home directory? To explain myself:

Many themes (and plugins also) load language files from a dedicated directory. E.g:

wp-content/themes/[themename]/languages

or:

wp-content/themes/[themename]/library/languages

[locale].php and [locale].css work fine from the home directory of the theme, but don’t seem to make any difference when put into a specified dedicated directory for languages. Am I missing something?

[ryan]

The .php file goes into wp-content/languages along with the main .mo.

[demetris]

Sorry, I did not make myself clear.

I’m talking about localizing *themes*. Themes (and plugins) can have their MO files in a dedicated directory. But if you put a [locale].css or [locale].php file in that dedicated directory, WP does not see it.

For example, in Thematic:

wp-content/themes/thematic/library/languages/el.mo

wp-content/themes/thematic/library/languages/el.css

wp-content/themes/thematic/library/languages/el.php

WordPress loads the MO file, but not the CSS and PHP files.

If I do this:

wp-content/themes/thematic/library/languages/el.mo

wp-content/themes/thematic/el.css

wp-content/themes/thematic/el.php

Then WP loads everything.

[ryan]

Ah, okay. There is currently no way to make WP look for the locale .css and .php in a subdirectory.

[demetris]

Thanks, Ryan!

[hakre]

Replying to demetris:

Sorry, I did not make myself clear.

I’m talking about localizing *themes*. Themes (and plugins) can have their MO files in a dedicated directory. But if you put a [locale].css or [locale].php file in that dedicated directory, WP does not see it.

For example, in Thematic:

wp-content/themes/thematic/library/languages/el.mo

wp-content/themes/thematic/library/languages/el.css

wp-content/themes/thematic/library/languages/el.php

WordPress loads the MO file, but not the CSS and PHP files.

If I do this:

wp-content/themes/thematic/library/languages/el.mo

wp-content/themes/thematic/el.css

wp-content/themes/thematic/el.php

Then WP loads everything.

sounds like a nice feature for the thematic theme. please consider suggesting the idea there.

[Daedalon]

#11226 duplicate/related.