Oscar Estepa
Forum Replies Created
-
Forum: Plugins
In reply to: [WP FullCalendar] How to translate days and months in the calendar ?Hello everyone,
I have been checking the new translation capabilities for the JS part of the plugin and there’s a problem merging translations from Events Manager 5.2+ (around lines 86-123) and “extra” translations (around lines 124-130).
The problem is that when array_merge finds a a key in $wp_fullcalendar_languages that already existed in $calendar_languages, it doesn’t merge the values, instead the keys from the latest array substitute those from the first one, i.e., for ‘es’, ‘pt’, ‘fr’ and ‘de’ the only translations we see are those corresponding to “buttonText”.
I have changed the line:
$calendar_languages = array_merge($calendar_languages, $wp_fullcalendar_languages);
to
$calendar_languages = $calendar_languages + $wp_fullcalendar_languages;And the content gets translated properly. @marcus if you think this fix will do, could you please add it to the following release?
Also, this is a big step forward towards localising the plugin, so many thanks for your hard work!!!! However I miss a filter which would allow us to modify $wp_fullcalendar_languages or even extract the text to the pot file so we can translate the strings the normal way.
great news! let us know when this is ready!
Many thanks in advanceForum: Plugins
In reply to: [WP FullCalendar] Calendar not displaying since 3.5 WP upgradethat’s great! I just tested and it’s working fine!
thank you for the quick answer @marcusBTW I saw in the changelog that it is possible to localize the plugin now, that’s great news! I was in bad need of that feature 😉
Forum: Plugins
In reply to: [WP FullCalendar] Calendar not displaying since 3.5 WP upgradethat’s great news thanks a lot @marcus!
If you need help testing the update let me knowForum: Plugins
In reply to: [WP FullCalendar] jQuery 1.8.x & curCSSHi, there’s a related thread here:
http://wordpress.org/support/topic/calendar-not-displaying-since-35-wp-upgradeA workaround is proposed by Christian, I tested it and is working ok, so I created a patch file if you want to use it for the time being, until the wp plugin is updated.
Forum: Plugins
In reply to: [WP FullCalendar] Calendar not displaying since 3.5 WP upgradeHi everyone,
Here is a patch to apply the changes suggested by Christian
http://dl.dropbox.com/u/14521892/fullcalendar_js_patches.patchIf you use Linux copy the file to the root of your site and run this command:
patch -p1 < fullcalendar_js_patches.patchBTW thanks to Christian to point us out in the right direction!
I hope the developers of this plugin include the fix in next version!
I just hooked into EM_TAXONOMY_CATEGORY_SLUG which is defined in em-posts.php and which I think is the one I need to change to alter the URL. It seems to work on Events > Settings > Pages > Permalink Slugs, the Event Categories field changes for English and Spanish, however it does not work anywhere on the site, I still get:
es-ES: http://mysite.com/eventos/categorias/conciertos
en-US: http://mysite.com/en/eventos/categorias/concertsThis is the filter I’m using:
function em_wpml_dbem_taxonomy_category_slug($option){ $lang = get_bloginfo('language'); if( $lang === 'es-ES' ){ $option = 'eventos/categorias'; } else { $option = 'events/categories'; } return $option; } add_filter('pre_option_dbem_taxonomy_category_slug', 'em_wpml_dbem_taxonomy_category_slug');add_filter(‘option_dbem_taxonomy_category_slug’, ’em_wpml_dbem_taxonomy_category_slug’);
Note that I used a pre_option and option filter to just to make sure, in case the option_ was not enough…It seems like the plugin is using the database option value to build all urls and this bypasses my filter, is that so?
I think I didn’t explain myself properly, let’s say I have a multilingual site, Spanish as main language, English as second. I go to
Events > Settings > Pages > Permalink Slugs
and set Event Categories field to:
eventos/categorias
So my event categories will have the following urls:
http://mysite.com/eventos/categorias/conciertosThe problem is that in English I get:
http://mysite.com/en/eventos/categorias/concertsThe events/categories part cannot be translated afaik
By the way, thanks for your time!!!
that reference is great to change an event permalink, however I’m trying to modify Events Categories which does not seem to be possible as there is no such a hook as ’em_event_categories_get_permalink’
Hi, to see the plugin translated you need to save the file in .mo format (easy with POEdit) and paste it in:
/wp-content/plugins/tweet-blender/lang/With a filename like:
tweetblender-nl_NL.mo
tweetblender-ru_RU.mothat is:
tweetblender-<your-locale>.moThe only problem with this approach is that you will lose your translation when upgrading the plugin, to avoid that, I recommend the following method instead:
1. Add this code to your functions.php:function custom_plugin_language_dir() { load_plugin_textdomain('tweetblender', false, '../languages/'); } add_action('after_setup_theme', 'custom_plugin_language_dir');2. Save your .mo file to /wp-content/languages/
There you go! your translation will be update-resilient!
Hi, did you ever got this working? If so, I’d appreciate if you could share your wisdom 😉
Sorry to disagree, but in the options panel you can only enter text for some of the strings, but you cannot translate strings like:
Days, Hours, Minutes, Seconds
NN% completed!Among others.
Ok, I just spotted the problem, all translation functions in the admin part (settings.php) contain the text domain string ‘dpMaintenance’, i.e.:
_e('Enter an URL or upload an image for the logo.','dpMaintenance');However none of the strings in the front do:
<h3><?php _e("Days")?></h3>It would be great to include the text domain for all strings in the front part so the plugin could be fully localised. I’m afraid that for the time being I have no choice but to hack the plugin, I’m I right?
you’re welcome klogan2, glad to be of help!
Hi, I think this problem is a duplicate or very similar to this one.
I left this comment there in case it is of any help.
Hi everyone, in case you are still having problems with this, I have spent many hours debugging this and finally the fix is a little hack to the plugin css:
comprehensive-google-map-plugin/style.cssYou need to delete the top:100000px !important; part from line 87
object.cgmp-data-placeholder{background-color:transparent !important;border:none !important;height:0 !important;left:10000000px !important;line-height:0 !important;margin:0 !important;outline:medium none !important;padding:0 !important;position:absolute !important;top:100000px !important;width:0 !important;z-index:9999786 !important}This will make the page resize correctly. I’m not a CSS expert so probably there’s a better solution without hacking the plugin, but it works for me for now.
Also I have to say that this problem happened when using Responsive theme v1.7.2 along with Comprehensive Google Map Plugin v7.0.29. There is a conflict between these two elements, specifically between the plugin CSS line shown above and the fitVids javascript function located in theme file responsive/js/responsive-scripts.js. This function handles resizing of video inserted via <object>, <iframe> and <embed> elements when the page is resized or when using mobiles and tablets. However the function processes all object elements even google maps’, the problem here is that google maps object does not have a defined height and width (in fact the object is hidden) which causes the function to “crash” when doing operations such as:
aspectRatio = height / $this.width();When processing a google maps object the result is:
aspectRatio = 0 / 0 = NaNSo even though removing top:100000px fixes the huge height/width problem, it would be great if the theme was modified to distinguish between video <object> and Google Maps <object> in order to treat them differently. And ideally either the theme or the plugin should be able to resize the actual <div> for the displayed Google Map.
Anyway I think this is a brilliant plugin and the responsive theme is also great and it’s really a pity that people stopped using it because of this “huge” problem which can be fixed by just changing a line. I’ll write to the plugin and theme authors to see if I can help them in anyway to get this fixed.