100% translatable and localizable on WordPress.org about oik HOT 31 CLOSED

Some of the build routines for oik plugins are implemented in bobbingwide/oik-i18n/issues/1. In makeoik.php we extend the standard logic in makepot by adding rules for detecting translatable strings.

If we simply change the code to perform translation of the parameters using standard WordPress i18n functions then the translations will be attempted multiple times.
The whole point of the original code was to reduce the number of calls to translate().
To support compatibility with plugins that have not been changed we need to provide versions of the functions that do not perform translation. We'll use a static method approach, implementing a class called BW_ ( or similar ) delivered as a shared library.

Code changes will be required for every translatable string.
e.g.

p( "This box intentionally left blank" );

would need to be changed to

BW_::p( __( "This box intentionally left blank", "oik" ) );

There are approximately 25 functions that performed translation under the covers. Each of these will require a method in the BW_ class which doesn't implement the translation.

from oik.

Implementation notes:

• We're developing PHPUnit tests for the new methods
• We're developing regression tests for the code that will be changed to use the new methods
• Some of the original functions are also being changed
• Some of these are delivered as shared libraries
• So, for the tests to pass, especially if tracing is activated, we may have to apply the changes to the shared library versions

from oik.

There are some cases where the original strings being translated were incorrect.
e.g.
Check this is you don't want to use the oik provide CSS styling

These should be corrected, then re-translated.
Check this if you don't want to use the oik provided CSS styling

from oik.

There are also cases where the original translatable text is written in UK English. It would be better if written for US English. A UK English version would contain the translation.
In oik, I've only found one instance where the text needed 'correction' from 'behaviour' to 'behavior'. I've implemented automatic checking in the oik-i18n plugin.

from oik.

There is also one case where an unexpected result is returned from translate. Raised as TRAC 41257 there are at least 2 workarounds.

1. Don't attempt to translate a null or empty string.
2. Drop automatic translation of the second parameter to bw_skv(). This will mean that a translation of "0" will not be loaded for the oik domain, so translate() will not find it to return.
3. Change the PHPUnit test cases that detected this problem either to apply the workaround or to pass now and fail later. Once the translation of "0" has been removed it'll need to be added programmatically, as in the wordpress-develop-tests.

from oik.

As documented in bobbingwide/oik-libs#7 I have now decided to implement a solution where shared libraries obtain their translated strings from the existing language files that have been loaded by the plugins / themes.

There are three parts to the solution.

1. WordPress continues to support the use of null for a domain name
2. We provide a shared library file called oik-l10n that supports translation of strings that have been accumulated into the null domain,
3. Shared library files use null for the domain name.

from oik.

When updating bw_copyright() we should improve the code to support replacement variables
and to allow improved formatting using CSS.
e.g the ". All rights reserved." suffix should be split into multiple parts with the "All rights reserved." part being in a nested span class="suffix" tag.

from oik.

oik_l10n_load_domain() should cater for the fact that when the default language is en_US the global $l10n may be empty. It should still create a merged domain, although this merged domain will obviously not contain any translations.

from oik.

The logic in libs\oik-sc-help.php should be updated to support the identification of shortcode parameter values which are translatable and those which are not.

The library file currently uses oik_require() to include includes/oik-sc-help.inc, so it's not properly shared. Some functions with translatable text should remain part of oik. Others should be converted to use the null text domain.

The relevant logic needs to be extracted from the .inc file and re-implemented in a similar method to the functions in bobbcomp i.e. static methods.

As we implement i18n using __(), calls to bw_skv() will be changed to BW_::bw_skv().

from oik.

The first stage of changing libs\oik-sc-help.php and includes\oik-sc-help.inc is to move all the logic to the libs file. Then we'll migrate back the logic that's not needed in the shared library but only needed in oik, either reinstating it in oik-sc-help.inc or moving it to the most appropriate file.

When dependent plugins are updated they'll switch to using the shared library.

from oik.

embed__example() currently doesn't do anything. It should be improved. embed__syntax() should mention use of the optional src= parameter; which is referenced when the content is empty.

from oik.

Below is a summary of the count of the new functions and deprecated functions as of 25th September 2017. This indicates that the status of the internationalization project for oik is now at 35%.

Additional notes regarding conversion.

Since the functions bw_checkbox and bw_checkbox_arr were not listed in makeoik then
the strings weren't being extracted so translation couldn't have been performed on them.

Therefore it's OK to call BW_::label() in bw_checkbox(), so no need to change bw_checkbox_arr().
We do have to ensure that calls to these functions receive translated strings.

bw_translate() should mostly become __() with the required text domain depending on the source file.

bw_tt() performs deferred translation of #hint text for fields.

bwt() is only used by th()

li() simply calls lit() so we'll implement BW_::lit()

td() is sometimes used for text - the string should be translated. Consider using bw_td().
th() is also sometimes used for text, the string should be translated and bw_th() used instead.

bw_array_get_dcb() is a special case that performs translation for the default text.
Rather than replace the callback parameter with null when we've already performed translation
we should just change the call to bw_array_get().

retimage() - title parameter should be translated using __()

from oik.

The help, syntax and example functions for the [bw_code] and [bw_codes] shortcodes should be implemented in shortcodes/oik-codes.php and tested in tests/test-shortcodes-oik-codes.php.

Note that the functions are dormant in oik.
The [bw_code] and [bw_codes] shortcodes are activated in the oik-sc-help plugin.

from oik.

Note: The syntax for [bw_directions] needs to be improved to include all the other parameters it supports. This could be in a separate issue.

from oik.

The syntax for the [playlist] shortcode needs improving

• ids parameter was incorrect; missing a >.
• id parameter default 'current post' should be changed
• orderby parameter values should not be italicised

from oik.

In the syntax for a number of shortcodes, the words describing the possible values are within <i> tags and for others they’re not. This inconsistency could be improved. For this issue, it’s more important to ensure that the words that are translatable are translated and the words that aren’t are not. E.g numeric would be translated to nmureic in the bb_BBlocale but true would not be.

from oik.

The syntax for [bw_wtf] needs to be corrected and the shortcode improved to cater for the variables used in the text that prefixes the hidden content.

from oik.

The functions in includes\bw_register.inc need special consideration regarding internationalization and localization.

The bw_default_labels() function, when passed the plural version in the 'label', works fine for en_US and en_GB,

Note: The default value of 'Post', used when 'label' was not set, was incorrect. It should have been the plural 'Posts'.

Changing the code to perform translation with substituted values should be OK for those languages where it's acceptable to replace either the singular or plural version of the original label, lower cased if necessary in a parameterized string.

In cases where this doesn't work, then it may be necessary to implement one or more filter functions.
This can be done early, in response to the register_post_type_args filter.
Or it can be done later, in response to the post_type_labels_{$post_type] filter, which is called by get_post_type_labels().

For oik we'll change bw_default_labels() and bw_default_taxonomy_labels().
The code for bw_register_field() will not be changed, but routines using it will need to ensure translated strings are passed where necessary i.e. $field_type and $args['hint'] instead of $args['#hint'].

from oik.

According to the output of my greprecated routine the internationalization work for the oik base plugin is now 100% complete.

Notes:

• The Total number found reduced when https://github.com/bobbingwide/greprecated was changed to ignore the tests directory.
• A pre-requisite to the tests is that the Site Language is set to English UK and that bb_BB language files for WordPress are available.
• The tests were written for my local development environment ( qw/wordpress ).
• They've been run with WordPress 4.8.1 and WordPress 4.8.2 under PHP 7.0.7 and PHP 7.1.1.
• Some tests are dependent on the settings in that environment. e.g. the values for oik-options.
• They may also be sensitive to the absence or presence of other plugins.
• Over time the tests will be generalised so that they should work regardless of the environment they are run in.

from oik.

When run in different environments a number of tests fail. Most of these are easily explained as differences in settings. e.g. values of oik options or other WordPress settings which have been overridden. But there are also cases where the tests did not complete due to Fatal errors.
Performing problem determination on the Fatal error has not been easy.

• The results vary depending on PHP version
• The results vary depending on sequence in which the tests are run
• Failures occur in different places
• Reports of memory usage indicate that the maximum allowed memory is being reset!

Rather than spend time looking into the Fatal error I have re-sequenced the tests and the test suite now runs to completion.

from oik.

Re: altering the tests for other environments.

Since the tests are dependent upon bw_translate producing a Deprecated notice we need to define BW_TRANSLATE_DEPRECATED to true if not already set.

from oik.

For some reason, when run in qw/oikcom the siteurl option gets altered to http://qw/src. It should be https://qw/oikcom. Obviously, this should not happen.

Explanation

• This is due to the logic in tests\test-shortcodes-oik-domain.php.
• In Tests_shortcodes_oik_domain::test_bw_wpadmin() we update the siteurl option.
• We expect the transaction to be rolled back at completion of the test,
• The rollback doesn't happen since the some of the tables, including wp_options, are MyISAM.
• They need to be converted to InnoDB.

Solution

Convert the tables to InnoDB, using oik-batch's oik-innodb.php routine.
Correct the value for siteurl.

from oik.

The tests are currently dependent upon certain plugins and themes being installed, some of which need to be activated. Shared libraries are expected to be the latest version.

Once the tests pass in the different environments being used then the code can be further generalised to remove these dependencies.

from oik.

Changes for environmental independence included:

• Using bw_update_option() to set oik options variables to match those used in qw/wordpress
• Using update_option to set WordPress posts_per_page option to 10
• Adding pre-requisite tests to ensure there are no pages with certain post titles

The tests now run to completion in qw/oikcom and qw/hm

from oik.

Some changes for environmental independence in WordPress Multisite are necessary. This includes changes in oik-batch.

• oik-phpunit.php - a new driver routine for PHPUnit
• New helper functions for multisite

from oik.

When I first installed oik v3.2.0-RC1 on oik-plugins.co.uk I got the following Fatal Error
Fatal error: Uncaught Error: Call to undefined function oik_l10n_enable_jti() in oik/admin/oik-admin.inc:28
when attempting to visit wp-admin.

Explanation

• This was because the oik-l10n library had not been loaded.
• v0.0.8 of the oik-lib plugin was activated at the time.
• It didn't matter what the value of the Enable as Must Use plugin? was.
• oik_require_lib_wrapper( 'oik-l10n' ) had failed since the shared library was not registered.
• and v0.0.8 did not yet implement fallback logic. bobbingwide/oik-lib#3

Workaround

• When oik-lib was deactivated it worked.
• Upgrading to v0.1.0 also resolved the issue.

Proposed solution

• oik should register the 'oik-i10n' shared library

from oik.

Oh dear, having released oik v3.2.0 to wordpress.org I find that nearly half my strings are missing from the en_GB files. This is due to differences between my version of makepot and the one used in WordPress. My logic also parses .inc files. I’ve used this extension since the year dot. Looks like I’m either going to have to convince people to change makepot or I’m going to have to eliminate strings from .inc files.

Changing makepot, which would have been a one line change, was not acceptable for wordpress.org so I’m going down the route of moving logic from .inc files to .php files and marking the .inc files as deprecated in v3.2.1. This also gives me the opportunity to cleanup niggles such as using explicit require statements within shared library files.

from oik.

Having converted the relevant .inc files to .php files. 10 translatable strings remained in the oik.pot file created by makepot. These were from includes/deprecated.inc. It’s high time this file was sent to the bit bucket. The functions had been deprecated donkey’s years ago.

from oik.

Some strings need adjusting for US / UK English.

e.g: should have been e.g.: - See #88 (comment)
post code or zip code should have been postcode or ZIP code

and 'Howdy,' should have been translated to 'Hi,' in the UK English version of 'Howdy,' replacement string.
Props @GaryJones

Note: It was correctly processed for the bb_BB locale as 'Hwody,' rpealecemnt srtnig... indicating some more work's needed on the local variants lookup table. See bobbingwide/oik-i18n#3

from oik.

@GaryJones has found more strings to change: Googlemap, Extended-address and e-mail.

from oik.

All PHPUnit tests pass in multiple environments. The tests implemented in oik-libs also pass for single site. I'm going to close this on the second anniversary of raising it!

from oik.