bubdev
Forum Replies Created
-
Forum: Plugins
In reply to: [Posts in Sidebar] Custom fields missing in dropdown listHello aldolat,
when controlling the content limit of a custom field, in some cases I’m getting weird glyphs instead of the proper last letter. I think it happens with umlauts and accents.
Here is a screenshot: http://uploadpie.com/uta2u
Best regards
bubdevForum: Plugins
In reply to: [Posts in Sidebar] Custom fields missing in dropdown listWorks great. Thanks again!
Forum: Plugins
In reply to: [Posts in Sidebar] Custom fields missing in dropdown listSorry, I just saw your question above.
I think it’s mainly a question of personal preference but can also depend on project specific priorities.
From a designer’s perspective I’d say limit it by characters, because it allows for more symmetric blocks of content, and it’s certainly better for very short texts (1 or 2, max. 3 narrow lines of text).
For longer texts I think a word limit usually looks more appropriate.
So in respect to what I guess is the majority of use cases, I’d implement a character limit (if both options are not an option :)).
Forum: Plugins
In reply to: [Posts in Sidebar] Custom fields missing in dropdown listWonderful! Thanks for the great support. And I’ll happily wait for v.3.3.
Best
bubdevDear Support,
I know this is a free support forum, so I’m not expecting too much effort in answering my question. A simple “No, we dont’t consider this important” would be acceptable. Much more than the kind of response I have received on this subject so far (starting here: https://ww.wp.xz.cn/support/topic/overriding-language-file).
It can also be considered a pre-sales question, since I’d like to use the plugin on many future client websites. But struggling with this little issue I’m not yet sure I can.
So may I ask you to give it another shot?
So, given that everything works out the way I hope it does, the problem could be solved by replacing this single line inside events-manager.php:
load_plugin_textdomain('dbem', false, dirname( plugin_basename( __FILE__ ) ).'/includes/langs');… with the following lines:
function load_plugin_textdomain() { $domain = $this->plugin_slug; $mo_file = WP_LANG_DIR . '/' . $domain . '/' . $domain . '-' . get_locale() . '.mo'; load_textdomain( $domain, $mo_file ); load_plugin_textdomain('dbem', false, dirname( plugin_basename( __FILE__ ) ).'/includes/langs'); }That’s true. But there you’re only defining the path to the plugin’s language directory:
load_plugin_textdomain('dbem', false, dirname( plugin_basename( __FILE__ ) ).'/includes/langs');And you’re not allowing for an alternate path, in case a customized version of the .mo-file is stored inside the WordPress language directory. Just like in the example above:
$mo_file = WP_LANG_DIR . '/' . $domain . '/' . $domain . '-' . get_locale() . '.mo'; load_textdomain( $domain, $mo_file );That’s all my post was about. Or did I miss something else?
Hi,
I hope it’s okay to continue my old thread. I recently came across something that would be a user friendly solution for what I consider a (little but important) shortcoming in this otherwise great plugin.
As a refresher, I was asking for a way to customize the language file in an upgrade safe way. Most of the bigger plugins I use allow me to safe my customized .po and .mo files to wp-content/languages/plugins [or: /plugin-name] or in a specifically named folder inside my theme’s directory.
So couldn’t you therefore just allow for an alternate path to a customized language file where the plugin’s textdomain is beeing loaded? Something like:
function load_plugin_textdomain() { $domain = $this->plugin_slug; $mo_file = WP_LANG_DIR . '/' . $domain . '/' . $domain . '-' . get_locale() . '.mo'; load_textdomain( $domain, $mo_file ); load_plugin_textdomain( $domain, false, dirname( plugin_basename( __FILE__ ) ) . '/lang/' ); }I copied the snippet from this post. http://fooplugins.com/make-a-wordpress-plugin-translations/
I think that’s how other plugins I use are handling it. Maybe I miss something and you guys have a good reason not to. I just wanted to adress this again, because it really matters on client sites that have to use specific terms in their language. And at leas I don’t always remember that I have to upload my customized mo-file after the update.
I’m also not sure what Caimin meant by “different way of translating” in his answer the last time I adressed this.
Thanks!
bubMay I ask you again, if EM does allow for a solution?
Thanks
bubHi Angelo,
yes that’s exactly what I was trying to achieve.
bub