WordPress.org

Ready to get started?Download WordPress

Forums

Events Manager
[resolved] Localization error in events-manager.php (minor bug, easy fix) (4 posts)

  1. milanouser
    Member
    Posted 1 year ago #

    There is a bug in the localization part of events-manager-source.js

    PLEASE FIX, because bug in core files, not in customizable template files!
    Both in events-manager.php and in includes\js\events-manager-source.js there is a mixup of weekdays in ITALIAN: dayNames and dayNamesShort both start with Monday (lunedi) instead of Sunday (domenica). To display correctly, they should start with Sunday.

    Files should be fixed to the following strings:
    events-manager.php, line 338:
    'it'=>array('closeText'=>'Fatto','prevText'=>'Precedente','nextText'=>'Prossimo','currentText'=>'Oggi','monthNames'=>array('Gennaio','Febbraio','Marzo','Aprile','Maggio','Giugno','Luglio','Agosto','Settembre','Ottobre','Novembre','Dicembre'),'monthNamesShort'=>array('Gen','Feb','Mar','Apr','Mag','Giu','Lug','Ago','Set','Ott','Nov','Dic'),'dayNames'=>array('Domenica','Lunedì','Martedì','Mercoledì','Giovedì','Venerdì','Sabato'),'dayNamesShort'=>array('Dom','Lun','Mar','Mer','Gio','Ven','Sab'),'dayNamesMin'=>array('Do','Lu','Ma','Me','Gi','Ve','Sa'),'weekHeader'=>'Wk','dateFormat'=>'dd/mm/yy','firstDay'=>1,'isRTL'=>false,'showMonthAfterYear'=>false,'yearSuffix'=>'')

    events-manager-source.js, line 414:
    $.datepicker.regional['it']={closeText:'Fatto',prevText:'Precedente',nextText:'Prossimo',currentText:'Oggi',monthNames:['Gennaio','Febbraio','Marzo','Aprile','Maggio','Giugno','Luglio','Agosto','Settembre','Ottobre','Novembre','Dicembre'],monthNamesShort:['Gen','Feb','Mar','Apr','Mag','Giu','Lug','Ago','Set','Ott','Nov','Dic'],dayNames:['Domenica','Lunedì','Martedì','Mercoledì','Giovedì','Venerdì','Sabato'],dayNamesShort:['Dom','Lun','Mar','Mer','Gio','Ven','Sab'],dayNamesMin:['Do','Lu','Ma','Me','Gi','Ve','Sa'],weekHeader:'Wk',dateFormat:'dd/mm/yy',firstDay:1,isRTL:false,showMonthAfterYear:false,yearSuffix:''};

    So, besides the request to please fix these errors for the next release, could you please also explain why these localizations are hard-coded into core files? Worse still, all languages are included, bloating up file size. After all, there are localizations available, even localized jquery datepicker files. It's all there in the plugin already, so why not making things easier?

    Thanks anyway for this plugin. Really useful

    http://wordpress.org/extend/plugins/events-manager/

  2. Marcus
    NetWebLogic Support
    Plugin Author

    Posted 1 year ago #

    the source file isn't used, it's got an outdated source actually (will copy the source over and minify the main file next time).

    will fix that in the events-manager.php file

    to explain why, we don't want to include these in the JS side of things (e.g. jQuery datepicker files or on our js file), because it's one more js file to load and/or more data to send to browsers, having it in the core makes more sense.

    We don't add these to the localization template because

    a) it's a ton of new strings to translate, time consuming for us and translators
    b) this was ported over from the jQuery translations files.

    hope that makes sense! we would certainly consider moving this over to the localization files when time permits (i.e. we can immediately update the localization files whilst moving all this over).

  3. milanouser
    Member
    Posted 1 year ago #

    Hi Marcus,

    thanks for the swift replay - and thanks in advance for changing the em.php file(s) accordingly for the next release.

    I do understand your concerns about moving the translations out, but nevertheless I think this is the only "clean" solution, especially if you want to keep your plugin open for other localizations.

    Cheers

  4. Marcus
    NetWebLogic Support
    Plugin Author

    Posted 1 year ago #

    Would still consider moving those translations over in the future, however, since these are strings that will never changed, once they're added (and we have quite a few languages already) this is actually considerably faster and more efficient in various ways than using translation strings or external files provided by the UI. I'm still not sure it'd be the right move, but will leave that for a more spare-time-filled day :=)

    We first strated using external files like the jQuery UI library does, then we implemented into the JS file (which meant larger js files) and finally opted to do it this way.

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic