WordPress › Support » [Plugin: All-in-One Event Calendar] Available Translations

nelra
Member
Posted 7 months ago #

Hello!

For information on available translations and helping us translate the plugin further, please see:
http://trac.the-seed.ca/ticket/78

We will update this thread with available translations as they come.
Simply download the PO and MO files to your language folder and ensure that your locale is set correctly.

Currently we have:
German PO and MO

Check back for more! Also, if you have any translations or are working on a translation, please let us know.

http://wordpress.org/extend/plugins/all-in-one-event-calendar/
pandem
Member
Posted 7 months ago #

I have just added Spanish PO and MO to trac.
nelra
Member
Posted 6 months ago #

Thanks pandem and everyone else! We now have multiple translations from the community. Please do share anything more that you have! :-)
nelra
Member
Posted 6 months ago #

Spanish, German, Dutch, Swedish so far
OC2PS
Member
Posted 5 months ago #

I would like to submit a Hungarian translation.

But one problem with your plugin is that you haven't put in fields like month names (january, february, etc), day names (Mon, Tue, etc) etc in translation files. This makes the internationalization very weak.

Also, in Hungarian, the date format used is Y. m. d. Not sure how to set that.
josjo
Member
Posted 5 months ago #

All-in-One Event Calendar uses the WordPress function date_i18n to display dates. date_i18n in turn translate dates to the locale configured i WordPress. So if WPLANG is set to Hungarian then day and month names should also be displayed in Hungarian. No need to translate since it's already in the WordPress translation.

The date and time formats also follow the formats configured in WordPress. You can set date and time format in the plugin configuration page, but this only applies to input.
OC2PS
Member
Posted 5 months ago #

In WP config I've specified Y. m. d. so based on what you have said, it should work.

Problem regarding languages is that I have a multilingual site via WPML, which I think) uses lang variable.

Any chance you are planning to make this plugin WPML compatible?
http://wpml.org/documentation/support/wpml-coding-api/

WPML can already translate events and event categories.
nelra
Member
Posted 5 months ago #

There is now also a setting in the ai1ec settings for date format, as on certain pages the format is displayed slightly different than what might make sense with certain WP config settings. Can you please double check what value is in the ai1ec settings?
OC2PS
Member
Posted 5 months ago #

I am aware of it and that was the first thing I saw. In fact, that's where I was requesting the change. The dropdown in ai1ec settings is quite limited. Why not use a freeform field like WP settings?
OC2PS
Member
Posted 5 months ago #

Also, how do we solve the problem of month names, day names etc.?
nelra
Member
Posted 5 months ago #

Hi,

As above, common names like Month and Day are handled by WordPress translation - if you have your WPLANG setting to a language, but months are still in English, it can be a problem with the native WP translation. Setting WPLANG to a language should take care of all common names like Month and Day - if you see a specific page that isn't translated, while others are, we can test this further.

The standard dates displayed will be according to the WP settings, however we have the ai1ec specific date format settings to allow specification of JQuery date formats. We will look to expand that further, but were following standards set in JQuery libraries. The ISO 8601 will allow very similar to your setting for now and is primarily used in the Add Event page.
OC2PS
Member
Posted 5 months ago #

In my multilingual site, I am not using WordPress's translations i.e. .po .mo files for all 10 languages. I tied, but that just blows resource utilization out of the water.

Rather, I am using WPML, which allows me to translate content, and also to translate relevant strings.

If you add month names, day names etc to your own .po .mo files and use them from there, that would make things simpler, and acceptable to WPML users (most multilingual WP installations).
OC2PS
Member
Posted 5 months ago #

I did not mention it above, but hope you can see that WPLANG is not the way to go because it is limited to a single-language website (though the language doesn't have to be English). Therefore for multilingual websites, you need to look at providing a translation.
josjo
Member
Posted 5 months ago #

This may be solvable. But one thing I'm not clear on is how the plugin translation is handled when you use WPML? In a plain WordPress install the plugin translation depends on WPLANG and is loaded by calling load_textdomain. How does this work with WPML?

As a side note: I would like to help out, but WPML is proprietary and since I'm only a All-in-One Calendar user I'm not eligible for a free WPML subscription.
OC2PS
Member
Posted 5 months ago #

You can get WPML free as a developer
http://wpml.org/purchase/theme-and-plugin-developers/
OC2PS
Member
Posted 5 months ago #

I think WPML uses a "lang" attribute.

They ask which languages you want your site in, and which language is default.

Thereafter, by default you create pages in your default language (as defined in WPML, not WPLANG), and have opportunity to translate each page (i.e. create new pages in other *installed* languages). I think in reality, all these pages are same as WP pages/posts...I think what WPML does is group the pages in a particular way, associate pages with each other (as translations) and display/hide pages based on rules (a little bit like Pages widget allows you to hide pages)

I keep saying *I think* because I am guessing. Not being a developer, I'm not familiar with the intricacies of the system.
josjo
Member
Posted 5 months ago #

Sorry, no WPML for me since I'm not the plugin author. I did however find a WPML guide for theme translation which explains how it works.

The problem here is that All-in-One Event Calendar uses date_i18n to localize dates and that function relies on the WP_Locale class (locale.php) that is translated as part of the core WordPress translation. You would either have to roll your own date_i18n or somehow use WMPL to translate WP_Locale.

There seems to be information about this on the WPML forum, but I don't have an account. Maybe you could check it out.
nelra
Member
Posted 5 months ago #

Yes, I'm afraid we have no current solution to this as josjo mentioned we are using WP specific methods. We can explore possibilities here but it will take time as we already have a lot of new features being developed.

If you have resources for developing this we would gladly assist and would enjoy merging such work. As always, we can look at such things faster when done through Premium Support which would jump the feature development to the front of the list

Multi-lang is unfortunately something WP has left to non-core plugins. I had assumed you may be using a solution with multiple mo files and had not explored WPML previously. There should be a way to get this to work with WPML as josjo mentions, but would need some exploration
OC2PS
Member
Posted 5 months ago #

Thanks, Josjo!

I checked out the WPML forum...info on this topic (date localization) seems rather scant.

Would be so much easier if All-in-One Event Calendar can use this info (month and date fields) directly from its own .mo .po files....using from WP files doesn't help much because without its own .po .mo files All-in-One Event Calendar would be useless anyway...I mean if ai1ec doesn't have a Japanese translation, and a Japanese site installs ai1ec, then merely grabbing month names and date names from WP .mo is little consolation...ai1ec is only useful to the Japanese site if ai1ec has its own Japanese .mo

There are only 2 real ways for using WP for multilingual sites - WPML and qTranslate

P.S. nelra, you might want to consider grabbing a free copy of WPML and having a poke around
nelra
Member
Posted 5 months ago #

Correction - I meant to say I hadn't tested WPML using the non-mo method, which seems to be causing the issue here. Will have to set aside time later for testing different methods. For other people reading, though, using standard mo-based WP translations shouldn't have an issue

OC2PS, can you point me in the WPML docs how you have yours setup to not use WP's mo files? How do you handle general theme and WP core translation?
OC2PS
Member
Posted 5 months ago #

WPML does not require .mo files. The fact of the matter is that there are very few items on the site frontend where WordPress needs to show its face (these would be things like the word "Search" or "Blogroll"). The primary purpose of WPML is to present multilingual content.

http://wpml.org/documentation/translating-your-contents/

http://wpml.org/documentation/translating-your-contents/creating-translations-manually/

My site is available in 10 languages, thanks to WPML, which offers 2 options - either use .mo files for each language (which is a resource bomb for shared hosting) or use WPML's string translation function, whereby you can translate key string within WP core as well as plugins (meaning if ai1ec were using month and day names as strings, I would be able to translate them in WPML without issues)

http://wpml.org/documentation/getting-started-guide/string-translation/

http://wpml.org/documentation/support/language-configuration-files/

This may be useful http://wpml.org/documentation/support/
And here's WPML API
http://wpml.org/documentation/support/wpml-coding-api/
OC2PS
Member
Posted 5 months ago #

ICL_LANGUAGE_CODE returns the 2 letter code for current language
OC2PS
Member
Posted 5 months ago #

nelra, any updates? thoughts?
josjo
Member
Posted 5 months ago #

@OC2PS:
As I said before I would like to help out, but it's impossible without WPML installed and I can't get it because I'm not a plugin or theme developer.
nelra
Member
Posted 5 months ago #

OC2PS, we will find time to look more into this but are not able to concentrate on WPML string-mode right away. My main thought though is that if you use Strings rather than mo files for translation of items, would this not be the place to translate the month names as well? I do wish to look further into this but must wait for other tasks that were already in line
nelra
Member
Posted 5 months ago #

What I meant to add was that as mentioned we are using a WP method for rendering dates. What if you have 10 plugins installed and they all wish to output dates using this method - would they all need their own method and translations? There is a very good reason for doing this in a central manner, and I think simply something is missing on the setup of WPML, it must be possible as-is without any modification - simply must find how
OC2PS
Member
Posted 5 months ago #

I uploaded WordPress's .mo .po files for the other languages. Didn't help. I still see March, April, ...Mon, Tue, ...etc

So it would seem that the compatibility problem is not just with WPML string translation but with WPML as a whole

P.S. By the way, if I use string translation, it allows me to translate things like Today, Post your event,...etc i.e. the strings you have listed in your .pot file. Unfortunately, you are trying to pick Day and Month names from WordPress .mo files..
nelra
Member
Posted 5 months ago #

We are not specifically picking translations, we are using a WP function which generates date strings based on site preferences (date format, timezone, etc): date_i18n

I would recommend consulting further with WPML about how to have it play well with date_i18n
OC2PS
Member
Posted 5 months ago #

You HAVE to pick day names, month names etc from somewhere, right? I am referring to the column headers and month name headers above table in calendar...etc
OC2PS
Member
Posted 5 months ago #

It's quite strange at the moment. Finally, on the first load, calendar shows Hungarian (e.g.) day names (but still not month names)...

But if I go to next month, everything is English. Worse, if I come back, everything (including day names) is English. And even weirder is the fact that if I then refresh the page then first the day names appear in Hungarian (while grayed and still with the loading marker) before changing to English when page is fully loaded.