• Localization of Full Site Editing themes

    Full Site Editing - Localization of templates and template parts

    The WordPress Gutenberg project’s plan for internationalization (i18n) and localization (l10n) of Full Site Editing themes (FSE) has not yet been formulated. I’ve written a proposal, entitled Internationalization and localization: translating templates and template parts, raised as Feature request #27402.

    I believe that very little needs to be done to Internationalize a file containing Gutenberg blocks and HTML, and that it can be translated and localized into a statically delivered file in the user’s required locale ( language and country ) using the process described in the feature request.

    This post briefly discusses some of the challenges of translating rich text content.

    Localization of FSE templates and template parts

    The example I used for a test case was:

    <!-- wp:column {"width":"50%"} -->
        <div class="wp-block-column" style="flex-basis:50%"><!-- wp:heading -->
        <h2>Translatable</h2>
        <!-- /wp:heading -->
        <!-- wp:list -->
        <ul><li>Color</li><li>Center</li><li>Check</li><li>Internationalize</li><li>Localize</li><li>Aluminum</li></ul>
        <!-- /wp:list -->
    <!-- /wp:column -->

    My automated process, did a fairly good job translating these strings into UK English, and a much better job translating them into my obfuscated language, bbboing ( locale bb_BB ), which is what I use for automated testing of the internationalization and localization of my PHP based plugins.

    US English (en_US)

     <!-- wp:paragraph -->
    <p>According to a researcher at Cambridge University, it doesn't matter in which order the letters in a word are, the only important thing is that the first and last letter be at the right place. The rest can be a total mess and you can still read it without problem. This is because the human mind does not read every letter by itself but the word as a whole.</p>
     <!-- /wp:paragraph -->
     

    obfuscated ( bb_BB )

     <!-- wp:paragraph -->
    <p>Accroidng tO A rseaecrehr At Cmarbdige Uinevsrtiy, It deosn't mtaetr In wihch odrer thE lteetrs In A wrod ArE, thE olny ipmroatnt tihng Is taht thE frist And lsat lteetr bE At thE rgiht palce. ThE rset cAn bE A ttoal mses And yOU cAn sitll raed It wtiohut porlbem. Tihs Is bceuase thE hmuan mnid deos nOt raed eevry lteetr by istlef bUt thE wrod As A wohle.</p>
    <!-- /wp:paragraph -->
     

    The automatic translations to UK English ( en_GB ) and bbboing ( bb_BB ) work because the translation process doesn’t attempt to make any sense of the content to be translated.

    What do translator’s need to be able to translate?

    There are now, and have always been, a few challenges deciding what strings need to be passed to translators. Most recently there was some content in a block pattern where the translators were given two parts of a sentence to translate. But, without the source code, there was no context. They had little idea that the two parts were in the same sentence.

    <p>Thou hast seen<br>nothing yet</p>

    This is a simplified version of the actual problem. If you want to see the details read https://core.trac.wordpress.org/ticket/51893 and check out https://build.trac.wordpress.org/browser/branches/5.6/wp-includes/block-patterns/large-header-button.php?marks=10#L10 for the absolutely hideous context.

    The problems are mostly associated with rich text that has been written, in US English, by someone who has probably not fully thought out the localization process.

    • Should the translator be given the full sentence including the <br>?
    • What about spaces and punctuation?
    • Is the <br>, or whatever other tag that might have been used, important?
    • When does the translator have to respect the tags used in the original?

    In my opinion, before we can finalize any solution for localizing the HTML we’ll have to agree some ground rules for internationalizing. The main problem areas that I have considered are:

    1. Sentences broken by inner tags.
    2. Assumptions associated with respecting leading and trailing blanks.
    3. HTML tag’s attributes.
    4. Text that should not be translated.
    5. Gutenberg block’s text attributes that should be translated
    6. Providing contextual help.

    Items 4., 5., and 6. can be supported by providing special tools in the block editor.

    What happens next?

    No one’s reviewed my proposal yet. Maybe you’ll have a chance to look at it once WordPress 5.6 has been shipped.

    It could be that the easiest solution to the problem is to allow the translator to use the block editor, loading the en_US version, and the target locale version, and saving the new version for the target locale.

    The source and target languages could be displayed side by side as in my English -> obfuscated example, or in multiple tabs for each block. A solution that doesn’t involve an offline process might be a great idea for Gutenberg Phase 4 – Multilingual Website Support.

    In the mean time, I wonder how Google’s automatic web page translator handles inner tags?



    Published:

    Last updated:

    December 6, 2020

Categories

Tide times from tidetimes.co.uk

Tide Times & Heights for Northney on
Thursday, 21 October 2021

Tide times from tidetimes.org.uk

Tide Times & Heights for Northney on
21st October 2021
00:40 High Tide ( 4.63m )
05:44 Low Tide ( 0.41m )
12:59 High Tide ( 4.83m )
18:05 Low Tide ( 0.47m )