100% translatable and localizable on WordPress.org

[bobbingwide]

The oik base plugin was developed in the UK English language using smart APIs that defer processing until the content is really needed. In some cases translation of language strings is deferred.

In order to create the .pot file we've been using a fork of the WordPress tool that searches for translatable strings and have extended it to handle a super set of APIs.

The WordPress translation tool used at https://translate.wordpress.org/projects/wp-plugins/oik
does not recognise these APIs. Therefore the set of strings to be translated is only a small subset of the actual set.

Two options

1. Change oik to use the WordPress APIs
2. Improve the makepot logic to support additional APIs depending on plugin/theme.

Each of these options have their Pros and Cons.
We'll not discuss these now other than for me to say that my preference is for option 2.
I'm just raising this as an Issue to be resolved.

[bobbingwide]

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.

[bobbingwide]

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

[bobbingwide]

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

[bobbingwide]

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.

[bobbingwide]

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.

[bobbingwide]

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.

[bobbingwide]

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.

[bobbingwide]

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

[bobbingwide]

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

Current	Change
Googlemap	Google map or Google Maps map
Extended-address	Extended address
Street-address	Street address
‘e-mail’	%1$s - email is intentionally hardcoded as an example of changing the prefix

[bobbingwide]

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!