You have a UTF-8 encoding issue. You are seeing single, unprintable bytes. That suggests the data is either stored in a single byte character set, or something is converting it from UTF-8 to a single byte character set. Regarding PO files (actually MO files are what WordPress reads). These need to be UTF-8 encoded. You … Read more
You already have the answer, but perhaps you’re not running your code early enough. Returning true from the override_load_textdomain filter will prevent all MO files from loading, but you’ll have to run it early to catch WordPress Core translations. Adding it as a must-use plugin does the trick for me: /* Plugin Name: Disable Gettext … Read more
You need to add an additional filter on the frontend. Very basically it would look like this: Frontend (eg. single.php): echo apply_filters( ‘my_custom_persian_filter’, $post_date ); Backend (eg. functions.php) function persian_date_function( $date ) { $date = $converted_to_persian; // there you convert date to persian return $date; } add_filter( ‘my_custom_persian_filter’, ‘persian_date_function’ );
In the General Settings page there is a “Site Language” option – if you select “English (United States)” and Save Changes, the localised version upgrade option will disappear. Selecting any other Language option will localise WordPress.
Looks like you correctly specified WordPress language code for other languages but not Japanese. https://make.wordpress.org/polyglots/teams/ Japanese .mo files need to be named themename-ja.mo but you are probably naming them using ‘jp‘?
Using the init action hook instead of the muplugins_loaded action hook did the job! But I wonder if that’s the proper way of doing it..?
I actually got a superfast response from the plugins mail. I’m assuming it’s cool if I make this public. I am wondering if I do I lose translations when I change my “Text Domain: xxxxx” inside my readme? Yes but … You can’t change that. Well, you can, but the WordPress translation system will always … Read more
You can’t use variables in translation functions. From the internationalisation documentation: The following example tells you what not to do // This is incorrect do not use. _e( “Your city is $city.”, ‘my-theme’ ); The strings for translation are extracted from the source without executing the PHP associated with it. For example: The variable $city … Read more
This must have been a conflict in my site. TBH, I wasn’t able to spot the conflict, but I was able to circumvent it by setting the necessary lang strings just before datepicker’s initiation like so: $(function() { $.datepicker.regional[‘el’] = { closeText: ‘Κλείσιμο’, prevText: ‘Προηγούμενος’, nextText: ‘Επόμενος’, currentText: ‘Σήμερα’, monthNames: [‘Ιανουάριος’, ‘Φεβρουάριος’, ‘Μάρτιος’, ‘Απρίλιος’, ‘Μάιος’, … Read more
The main problem is that you removed the sprintf. Replace the echo with sprintf and remove the (). Should be like this ‘logged_in_as’ => ‘<p class=”logged-in-as”>’. sprintf( ‘Logged in as <a href=”%1$s”>%2$s</a>. <a href=”%3$s” title=”Log out of this account”>Log out?</a>’, admin_url( ‘profile.php’ ), $user_identity, wp_logout_url( apply_filters( ‘the_permalink’, get_permalink( ) ) ) ). ‘</p>’, Be careful! … Read more