Tag Info

New answers tagged

0

Well, actually, you should view your site as requiring "multilingual" capabilities, even if the base language for both countries is identical, because the actual locale for each is nevertheless different. More specifically, you can create variant "translations" for your British ('en_GB') and Irish ('en_IE') localizations. A plugin such WPML (WordPress ...


0

Yes, you can load multiple translation files for multiple text domains in one plugin. This is sometimes useful, for example when you need just one string in AJAX calls and many strings in the rest of the application: to make AJAX faster, load a separate translation. Be aware, automatic language updates for the plugin from wordpress.org will probably not ...


0

While I can't see any major fault in doing the way I proposed initially especially in relation to translation and localization, what I realised while researching this issue was that I was asking an ajax question. Basically what's the most efficient method to initialize the I18n components of wordpress. Short of making a custom ajax hook like I had above, I ...


1

Use get_post_types( ['public' => TRUE ], 'objects' );. This will return the already translated post type labels and other information. Example for tests: add_action( 'wp_footer', function() { $post_types = get_post_types( [ 'public' => TRUE, '_builtin' => TRUE ], 'objects' // complete information, not just the name ); ...


0

Dan’s answer put me on the right path. In addition to the language files, a localized WP package also creates the $wp_local_package variable in wp-includes/version.php. If that variable is set, its value will be included in the version check URL and the response will then correctly say you’re using the latest version: ...


0

You can not translated dynamic strings with he translation API, you can translate only static strings that you know in advance.


1

The issue is, there is no value for local_package in the URL. At first I thought this might be a bug. Similar issues have been reported before (see here and here. I then stumbled on comment in trac ticket 8729 where user nbachiyski explains how localization should work: There are two ways to localize WordPress: Drop some translation files. ...


2

Instead of using poedit to generate your translation strings from your code, use the WordPress i18n tools to generate a POT file for you. This has the advantages of a) not needing you to do anything special in poedit and b) getting everything that is possible for translation, including headers and non-standard translation string calls (not everything is __ ...


1

Ok. I Found the problem. Several tutorials told me to put __() and _e() in my poedit. Which, now I've found the answer is pretty stupid. Because there simply don't exist any strings with these search values. As there is always something in between those brackets. Solution is thus very simple (and quite stupid). Put the search values to __ and _e



Top 50 recent answers are included