backdrop-contrib/i18n

Collection of modules to extend Backdrop CMS multilingual capabilities

Internationalization (i18n)

This is a collection of modules to extend Backdrop core multilingual capabilities and be able to build full-featured multilingual sites. This module makes possible:

• Taxonomy translation (both, per language terms and translatable terms)
• Enhances node translation
• Menu (item) translation
• Field label translation
• Internationalization for (core) contact forms
• Path "translation", for instance declare different views as translations of each other
• Synchronize field values across translated content
• Redirect visitors to the proper translation of current page, if available

Installation

• Install this module using the official Backdrop CMS instructions

Issues

Bugs and Feature requests should be reported in the Issue Queue

Upgrade from Drupal 7

Backdrop core took over several tasks for translations, so this module had to go through a bigger rewrite. Although it now contains less submodules, most of the functionality should still be available.

"Most" means, that some functionality had to be dropped or implemented differently.

A migration path from Drupal 7 is available.

Current Maintainers

Work is ongoing and we need help. If you're willing to test functionality and/or provide pull requests, feel free to open an issue. Your help is highly appreciated!

• docwilmot
• Indigoxela
• Help wanted

Credits

• Port to Backdrop CMS was begun by docwilmot
• Originally written for Drupal by Jose Reyero

License

This project is GPL v2 software. See the LICENSE.txt file in this directory for complete text.

i18n's Issues

Hook_autoload_info() duplicated

As above. "Merged without testing", famous last words. 😄

Submit buttons should be in 'actions' wrapper

To take advantage of core button styling, can we wrap submit buttons in an actions container? I can make a PR.

Deleting localized vocabulary gives error

Deleting a localized vocabulary with terms in it gives the following error:

Error: Call to a member function get_translations() on int in i18n_taxonomy_taxonomy_term_delete() (line 632 of /app/modules/i18n/i18n_taxonomy/i18n_taxonomy.module).

When I reload the page, the terms are gone and I can now successfully delete the vocabulary in a second attempt.

Wrap i18n_views back in

Pulling out a few comments from an earlier thread:

@laryn: Should i18n Views be wrapped (back) in since Views is in core now?

@mazzech: I used i18n Views several times, there are a few hickups, but the workarounds without the module are pretty dirty... ++ for having it migrated:-)

@indigoxela: Regarding i18n Views: I never needed it because views labels and header/footer text areas are translatable as-is, without any additional modules. At least in D7 - didn't need it yet in Backdrop. But if it works in D7, it should work in B core (or we should fix it there).

Localized terms and the page title doesn't work with the alternative "Taxonomy term" view

I'll try to get more information noted but wanted to write this down before I lost it: it seems that a vocabulary that is set to "Localization" as the mode of translation doesn't work quite perfectly with the "Page title" block that is available in the Layout. It always displays the source language for the Page Title.

Testing i18n - Taxonomy translation

I also tested Taxonomy translation at the same system and with same configuration described in the previous tests.

In the settings of the core dictionary Tags I activated Multilingual support with the option "Translate".

On admin/structure/types/manage/page/fields I added Term reference field Tags.

On a node on the site from Content type Page I added a few Tags in Bulgarian and then translated them into English and German.

Everything works perfectly, clearly, understandably and without any error messages.

I will not do more tests, I think that i18n is ready to work and I start using it in real sites. If there are problems in working with real sites, I will post new issues.

i18n_string localized term translation doesn't use CKEditor for description

I noticed when translating localized terms that the description displays HTML code instead of using the CK Editor as expected. PR coming.

Argument 1 passed to backdrop_sort() must be of the type array, null given

Recoverable fatal error: Argument 1 passed to backdrop_sort() must be of the type array, null given, called in /home/public_html/core/includes/token.inc on line 320 and defined in backdrop_sort() (line 6904 of /home/public_html/core/includes/common.inc).

Above error came when editing a field (happened on both a text field and an image field) while I had Internationalization (i18n), String translation, and Translation sets modules active. Disabled the last two (but left i18n enabled) and was able to edit the field.

Table i18n_translation_set already exists

Will need to check before trying to create the table. Not sure best way to do this since I think it's just defining it in the schema, not in an update hook.

Escape source name in taxonomy term translation form

Related to https://www.drupal.org/sa-contrib-2020-025

Migrate i18n_user data

Now in core (user.mail.json). Move from variable_store db table to locale module db tables with translation context pattern like config:user.mail:[name]

Creating vocabulary with multilingual turned off prevented

Found while testing something else...

• Go to admin/structure/taxonomy/add
• Create a vocab without multilingual options (keep "Multilingual support" unchecked)
• Save
• Get redirected to 404 page not found
• No vocab has been created (verified by searching in active config dir for a file taxonomy.vocabulary.[the name].json

Run Simpletests in travisCI

A comment in a previous Issue:

we should get these (Simpletests) to run in travisCI too;

That would be really cool.

@serundeputy I have no travisCI expertise at all, so I can't be much help here.

---

PR: #31

Cleanup CMI usage

Currently the config variable naming and structure is a bit messy.

It's fine to have most settings in one file (there aren't many), but they should get properly prefixed (for uninstall hooks in submodules and for easier identification).

i18n_menu issues

I'm going to poke around and see if I can get a few submodules running. I am testing i18n_menu and am running into this error when I try to configure a menu:

Fatal error: Maximum execution time of 30 seconds exceeded in /path/to/backdrop/core/includes/errors.inc on line 271

This is at admin/structure/menu/manage/main-menu/configure

Interestingly, admin/structure/menu/manage/main-menu/translate does not error out when visited. However, it does not function. Clicking on 'translate' reloads the page (with a language code appended to the URL, such as admin/structure/menu/manage/main-menu/translate/de) without proper breadcrumb or tabs.

i18n_taxonomy issues

Similarly to #2 -- when visiting admin/structure/taxonomy/tags/configure I get:

Fatal error: Maximum execution time of 30 seconds exceeded in /path/to/backdrop/core/includes/errors.inc on line 57

When visiting admin/structure/taxonomy/tags/translate the page shows up in an identical way to the issue with menus. Clicking a 'translate' link reloads the page sans proper breadcrumb and tabs:

Hopefully the similarities here mean that if we crack it on one it will make the other one easy to solve, too.

Migrate i18n_block data

Part of #33

"Needs a migration path from locale db tables to block.custom.[name].json (custom blocks only), Needs to run after system 1025 (see: hook_update_dependencies())."

This is what translated blocks look like in core right now (forgive my poor Dutch):

{
    "_config_name": "block.custom.my_english_block",
    "delta": "my_english_block",
    "info": "My english block",
    "title": "English!",
    "description": "",
    "body": {
        "value": "<p>Read my English words and behold!</p>\r\n",
        "format": "filtered_html"
    },
    "default_langcode": "en",
    "translations": {
        "nl": {
            "info": "Mijn nederlandse blok",
            "description": "",
            "title": "Nederlandse!",
            "body": {
                "value": "<p>Lezen op mijn nederlandse tal!</p>\r\n",
                "format": "filtered_html"
            }
        }
    }
}

I had to remind myself how we implemented it in core. Should also document here how it's done with i18n_block.

Migrate i18n_variable data

Migrate "Site details" (system.core.json) from variable_store to locale db tables with translation context pattern like config:system.core:[name]

    "_config_translatables": [
        "anonymous",
        "site_name",
        "site_slogan",
        "maintenance_mode_message"
    ],

Then drop db table variable_store? Maybe other i18n variable stuff could get migrated?

Link display setting to translated content went into core

Keep an eye on backdrop/backdrop-issues#2910 and remove the setting from i18n when/if it got merged.

The setting will ship with core version 1.18.0.

Views exposed filters

I've run into a case where I am exposing a filter of localized taxonomy terms on a View, but they display in the source language always.

We can probably pluck out a handler or two from i18nviews and add it to the i18n_taxonomy module.

Keep up with changes/fixes of the Drupal version

There have been several bugfixes and releases for i18n Drupal version since the Backdrop version got forked.

TODO: evaluate, which one's are usable and make sense for the Backdrop version (which is pretty much of a rewrite).

https://www.drupal.org/project/i18n/releases

Disable deprecated and remove modules during D7 upgrade

Perhaps we can disable i18n_variable, i18n_user, i18n_block in an update hook in i18n.install. And perhaps remove it altogether. Not sure the code is necessary if we have an upgrade path for variables defined in variable_store.

[META] Migration path from D7

These modules need a migration path, as functionality made it into core (or has gone or changed significantly).

• i18n_user
• i18n_block
• i18n_variable (partly, only what went in core via config translation)
• i18n_taxonomy
• i18n_menu

Pick your task, open a new issue, link it here...

Basic descriptions of TODOs (so far):

i18n_user #47

Now in core (user.mail.json). Move from variable_store db table to locale module db tables with translation context pattern like config:user.mail:[name]

i18n_block #35

Needs a migration path from locale db tables to block.custom.[name].json (custom blocks only), Needs to run after system 1025 (see: hook_update_dependencies()).

i18n_variable #48

Migrate "Site details" (system.core.json) from variable_store to locale db tables with translation context pattern like config:system.core:[name]

    "_config_translatables": [
        "anonymous",
        "site_name",
        "site_slogan",
        "maintenance_mode_message"
    ],

Then drop db table variable_store? Maybe other i18n variable stuff could get migrated?

i18n_taxonomy #34

Core now takes care of term language/langcode. So data from "language" column should get moved to "langcode" column.

i18n_menu #34

Move data from "language" to "langcode" column in table menu_links.

---

There's probably even more to do, but these tasks are tricky enough.

Especially the moving of translations from db tables to config or to other db tables. Module locale provides no helper function for that and i18n_string is unusable in this case, as the translation group is the default one ("Built-in interface").

Any hint is welcome.

Column not found: 1054 Unknown column 'textgroup' in 'field list'

Trying to translate any term at, for example, /en/admin/config/regional/translate/edit/1051 gives:

Error
Error messagePDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'textgroup' in 'field list': SELECT source, context, textgroup, location FROM {locales_source} WHERE lid = :lid; Array ( [:lid] => 1051 ) in i18n_string_locale_translate_edit_form() (line 294 of /var/www/docroot/modules/i18n/i18n_string/i18n_string.pages.inc).
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'textgroup' in 'field list': SELECT source, context, textgroup, location FROM {locales_source} WHERE lid = :lid; Array ( [:lid] => 1051 )

Will try to troubleshoot this tomorrow.

i18n_string: Textgroups in translation import have been removed from core

This module with all submodules still relies on textgroups when importing.

In D7 there are following groups on admin/config/regional/translate/import:

• Built-in interface
• Node types
• Menu
• Taxonomy

These form items got removed (core locale), so we need to update the functions that still assume they exist.

For instance i18n_string_textgroup() or i18n_string_locale_translate_import_form_submit().

As i18n_string heavily relies on textgroups, I guess we either have to bring them back to core or we implement everything in i18n.

Not sure yet.

This is some kind of showstopper for import/export of translation files when using i18n.

Related core issue: backdrop/backdrop-issues#4864

Ensure that textgroup is added back when upgrading from d7

I see that in i18n_string.install it will recreate the textgroup field in i18n_string_install() but for an upgrade that module is already installed. So perhaps also need it in an update hook that runs after textgroup is dropped in locale.install. (Unless we decide to revive it in core.)

Views and i18n [meta]

• #64 View that lists localized terms
• #63 Views exposed filters

---

Pulling out a few comments from an earlier thread:

@laryn: Should i18n Views be wrapped (back) in since Views is in core now?

@mazzech: I used i18n Views several times, there are a few hickups, but the workarounds without the module are pretty dirty... ++ for having it migrated:-)

@indigoxela: Regarding i18n Views: I never needed it because views labels and header/footer text areas are translatable as-is, without any additional modules. At least in D7 - didn't need it yet in Backdrop. But if it works in D7, it should work in B core (or we should fix it there).

i18n PHP compatibility

Check compatibility with PHP 7.4+

Tests currently fail on newer PHP versions. This task has low priority, though.

i18n_variable: backdrop_multilingual() does not exist

I get a fatal error on updating from d7 where it gets an undefined function backdrop_multilingual() which gets called in hook_init so pretty much all the time. When starting the upgrade i18n_variable is still enabled so we need to ensure this doesn't break things.

Cleanup i18n_path.install and i18n_node.install

That file is still messy and needs cleanup before even an alpha release can be considered (i18n_path_update_7000)...

Get i18n Simpletests working

All the modules have Simpletests, which currently don't work yet.

I'll see if I can get them back to life. Having working tests is crucial for a possible stable release.

Drop obsolete db table columns / tables and modules

The "language" columns need evaluation. Core provides new "langcode" columns that took over the job (taxonomy terms...).

As soon as #33 is done, drop the obsolete ones if that didn't happen yet. And, of course, also remove obsolete db table schemas from install files.

And remove the unportable/unported modules.

Applying to become co-maintainer

To get some progress with porting this module, I'm applying as co-maintainer.

Not that I suddenly think, that's a really smart idea. 😉

This module will need more helping hands and it seems unfair to leave it all to @docwilmot

View that lists localized terms

I've run into a case where a view that displays localized taxonomy terms is showing them in the source language always. There is no option (for example) for adding the term name in localized format.

We can probably pluck out a handler or two from i18nviews and add it to the i18n_taxonomy module.

Testing i18n - Multilingual content

Continue testing sub-modules of i18n.

Start with activating Multilingual content.

Message: You must enable the Content Translation module to install Multilingual content.
Would you like to continue with the above?

Click CONTINUE.

OK, no errors.

Go to: admin/structure/types/manage/page

Super! The same as known from Drupal 7!

There seems exists some error - I marked it with red on screenshot.

These options are especially useful and are not in the core multilingual settings:

• Set current language as default for new content.
• Require language (Do not allow Language Neutral).

For many users, this is a protection against unpleasant errors, if they forget to choose a language, the system saves page / node as Language Neutral and this leads to many problems, including transliteration problems and then search engine optimization problems.

It is great that the i18n solves this in Backdrop as well.

---

The good news ends here.

After making the changes presented in the above screenshot, I went to the home page, it is available, and has tabs View, Edit and new - Translate. Nice!

But when I try to access Edit / Translate of the front page, like any other old page on the site, created before Multilingual content activation, the site is covered by an error message:

In newly created pages everything works normally, those that were created before activating Multilingual content and the entered settings as in screenshot above are not available and show the above message.

Disable and uninstall Multilingual content.

Open and edit and save Page / Multilingual support again. I tried everything I could think of - I removed the Multilingual support option altogether, I deleted all URL aliases, I deleted the cached information many times, nothing helps - for all old pages, before installing Multilingual content I see the error:

At the same time, new pages created after the installation of Multilingual content work normally and perfectly.

Even worse, things didn't improve even after i18n was completely disabled and uninstalled.

I also deactivate and uninstall the Core module Content Translation.

Hooray, the pages are available again!

I activate the again Core module Content Translation

The pages are not available again and the same error is visible - The page isn’t redirecting properly.

I go to Page - Multilingual support - and turn on Enabled.

The pages are not available again and the same error is visible.

I go to Languages ​​and delete the Bulgarian language again.

The old pages begin start accessible again, although they disappear from the main menu, they are accessible through a content review, but in the Language field it of these pages it displays "None".

I am installing Bulgarian again.

The pages become inaccessible again, the same error is displayed - The page isn’t redirecting properly.

This time all the pages, even the test one page that worked newly created after the initial installation of Multilingual content - even this page no longer works.

Conclusions:

The Multilingual content module is not yet ready for use. Creates errors, problems that cannot be fixed even by completely disabling and uninstalling i18n.

This is a useful direction of work with great potential, but it is not yet ready for end consumers.

I like the direction i18n is going - so far I see an opportunity to use Field translation - this submodule works well. The associated String translation also seems to be working.

In the coming days and if possible I will test other submodules from i18n.

But I wonder if all the submodules in the i18n bundle need to be ready for the i18n to be officially introduced. Can't it be formalized gradually as the working modules are made official, while the rest are finalized.

What needs work

Noticed a distinct need for language related help, so this is a start on i18n. It will not work as is, havent tested, so dont use in production. Its here so hopefully we can collaborate and fix it. Also havent informed the Drupal maintainer yet either.

So far only work done is to get it installing without error and to get the settings page for the main module and i18n strings working. Have not touched any of the other submodules at all.

Please if you try this, list whats broken in detail, here.
Checking off below what I've verified installs without error. This is not indicating that it actually works, just that it doesnt crash.

Working:

• Block languages (mostly in core and in Backdrop blocks are pretty different)
• Contact translation
• #11 Field translation
• Internationalization
• #2 Menu translation (very complex because of conflicts with core menu handling)
• #8 Multilingual content
• Multilingual forum (has been ported and moved to a standalone project)
• Multilingual select
• Path translation
• String translation
• Synchronize translations
• #3 Taxonomy translation
• Translation redirect
• Translation sets
• User mail translation (is in core)
• Variable translation (required module Variable won't get ported)

Out of place text "Move book settings..." in i18n.install

If the update hook is needed (right now it's not doing anything) than perhaps update the doc to explain why instead of this boilerplate.

Get i18n_node submodule working

i18n_node isn't working yet.

How to reproduce:

Enable Internationalization and Multilingual content modules, go to admin/structure/types/manage/page

Besides several property: stdClass notices (different issue) there's an error:

Error: Call to undefined function variable_type_include() in i18n_node_form_node_type_form_alter() (line 419 of .../modules/i18n/i18n_node/i18n_node.module).

Function variable_type_include is provided by the variable module in Drupal. That module doesn't exist for Backdrop. Possibly it needs to get migrated, but maybe core or i18n module could provide the required functionality.

I'm aware that this module is far from being ready to release, but I thought a php error is worth an issue.

Notice: Trying to access array offset on value of type bool in i18n_menu_init() on 404 without language prefix

Notice: Trying to access array offset on value of type bool in i18n_menu_init() (line 967 of .../modules/i18n/i18n_menu/i18n_menu.module).

When the page (or path prefix does not exist), basically for every 404, but only if the language prefix is missing. Edge case.

Testing i18n - Menu translation

Activate Menu translation.

Message: You must enable the Translation sets module to install Menu translation.
OK, I also activate the Translation sets module.

Checking admin/config/regional - Regional and language

A new section has appeared - Translation sets - currently empty - No translation sets available.

I see another new section - config/regional/date-views - I don't know what it's for, but I'll probably find out later. For now, I ignore it.

I go to admin/structure/menu

And here I see the Translation sets tab - it is currently empty - No translation sets available.- I assume the same one, which is also available through admin/config/regional. I guess here data will appear in the process of working on the menus

I go to admin /structure/menu/manage/main-menu

There is a new option here - Translate Menu. It is strange that for Primary navigation source is Bulgarian. Guess why this is so and make changes to admin/config/regional/i18n/strings and set Source language - English.

I return to admin/structure/menu/manage/main-menu/translate

OK, now everything is normal, for Primary navigation I already have English (source)

I translate Primary navigation into Bulgarian and German.

Works properly, I think this is an additional useful option (which is not in the core) for a multilingual site with users / administrators using different languages.

I go to admin/structure/menu/manage/main-menu/configure.

OK, there's a whole new section here: Multilingual options. I know that from Drupal.

1. No multilingual options for menu items. Only the menu will be translatable. It is clear.
2. Translate and Localize. Menu items with language will allow translations. Menu items without language will be localized.
3. Fixed Language. Menu items will have a global language and they will only show up for pages in that language.

For point 3, I wonder if I need it because the Backdrop system does it with Core. I decide to see what the difference is and activate.

I see the difference. In a system without i18 n, menu items can be placed in different languages. However, i18n adds a new Translate tab to the Edit link page.

I translate all the pages, I also translate the menus. I already understand what Translation sets are - they have already appeared:

admin/structure/menu/manage/translation.

Conclusions:

For e Menu translation sub-module works reliably, I worked continuously for 5-6 hours on this test and made hundreds of settings, tests and changes, the system did not give a single error.

A useful option is to translate the name of the menu itself.

However, I don't understand what Translation sets and the translation of the links in the menu do in general, because in Core you can still set the language for the link and this works perfectly in core and the menu shows only the links that are with the language that is active on the site. So I wonder if this is necessary in Backdrop?

A new option is to create menus with a fixed language, this can be a useful option in some cases. Also No multilingual options for menu items. Only the menu will be translatable - may be useful in some cases

I believe that the module Menu translation is ready for use and can be officially published.

However, I assume that the benefit of Translation sets and menu links translation (which largely do something that the Backdrop core already does, unlike Drupal 7 where you need i18n for such functionality) will become clearer to me by activating the Path translation module in next tests or when adding Views links in different languages in menus. As far as I remember from old experience In Drupal 7, they work together (menus and paths), so I've done translations of pages made with Views that display content in different languages without translating from one View to another.

I would also be grateful for information on what config/regional/date-views is for.

Split out i18n_forum to a standalone module

As discussed in #1
Since the Forum module is a standalone contrib project in Backdrop, the related i18n_forum module should also get moved to an extra project.

Coding standard compliance

Currently there are a lot of coding standard violations in many files.

Pretty code is readable and easier to maintain code. So this will be my next step.

i18n_string: Views support for textgroups broken - move from core to i18n_string

Here's an extra issue for views support.

This is the related core issue: backdrop/backdrop-issues#4838

Background: textgroups per se have been ripped out of core, but there are several remainders. This should be fixed in both, core and i18n.
Proposed solution: move everything re textgroups to i18n - the only module using them.

Get i18n_field submodule working

Maybe not the most important, but after all an easy to port submodule.

i18n_field (Field translation) provides translation for field properties like labels and help text.

Throws error right after installation

I tested in a multsite environment, putting the module into /sites/demo1/modules/i18n-1.x

Right after activating the module, I got the error Error:

Class 'i18n_field' not found in i18n_get_object() (line 455 of /home/lugoture/www/SERVER/sites/demo1/modules/i18n-1.x/i18n.module).

Strange call of language_list()

While I'm starting to dig deeper into module code, I found a weird call of language_list():

i18n/i18n.module

Line 249 in f0c5c7e

return language_list($field, I18N_LANGUAGE_EXTENDED & $mode);

return language_list($field, I18N_LANGUAGE_EXTENDED & $mode);
This won't work as expected, because the function returns objects, leading to php errors later on.

https://api.backdropcms.org/api/backdrop/core%21includes%21bootstrap.inc/function/language_list/1

I found at least one change record: https://api.backdropcms.org/change-records/languagelist-now-takes-second-parameter-return-array-strings

Translating terms is not saving the language correctly

`When translating a term on a vocabulary with "translate" set (as opposed to "localize"), the language selection is set correctly and locked on the translation page, but the resulting term is saved as language undefined -- so it is not attached to the translation set.

As a workaround, I can then go in and edit the term, change the language to the appropriate language and save the term, then go back to the original term and link it in the translations tab.

This is on v1.x-1.0.0-alpha2. I don't see any errors or warnings in the log.

Taxonomy Translation Test

Hi @indigoxela thank you for doing the initial port... here's my first feedback

• Created a new vocabulary
• Chose the option "Localize"
• Create a term in three languages (EN = base language)
• Create a taxonomy reference field
• Create an article in EN, choosing the EN term
• Translate into FR, but the taxonomy field does not show the DE term as an option, which should be the case IMO

Testing of i18n - Field translation

Replying to @indigoxela:

@amilenkov cool, many thanks for offering testing the module (i18n)

First of all: i18n has its own issue queue

https://github.com/backdrop-contrib/i18n/issues

All your findings should be posted there.

backdrop/backdrop-issues#4720 (comment)

---

Testing of i18n-1.x-1.x - chronological record of actions

29-Nov-20 - download i18n-1.x-1.x as it is at 29-Nov-20 (from GitHub i18n project page)

The test site has the following configuration:

Backdrop 1.17.4

MySQL Database - MariaDB, or equivalent version 5.5.5-10.3.27-MariaDB-log
PHP - version: 7.3.23
Web server - Apache - Shared hosting

All additional modules with latest updated versions:

Backup and Migrate
BUEditor
Global Redirect
Shield
Copyright Notice
IMCE
Colorbox
Libraries (with Colorbox library)

Others:

Content Translation - purposely NOT active before i18n (I assume that this will create conflicts if it is active)
Language - Active
Locale - Active

The site is new, for real client not demo, under construction, there are only three Pages there, no custom blocks, views, default layout - Moscone Flipped, Home layout - Boxton, Default Administrative Layout - Boxton.

The goal is multilingual site with English and Bulgarian. Decide to use it with i18n and test i18n. If unsuccessful - I will restore the site from backup.

Theme: Bartik 1.17.4 (default theme)

---

Installation

Installing i18n-1.x-1.x via FTP

A whole new section appears in Functionality - Multilingual - Internationalization.

I decide to activate and test the modules in this section one by one.

Contact translation - for this site and usually in my work this module is not needed, I leave it inactive.

Activate Field translation.
Save Functionality Form.

Screen message:
You must enable the String translation, Internationalization modules to install Field translation.

Would you like to continue with the above?

I press Continue. OK, No error messages.

Test if Field translation works.

Go to Page Content Type / Manage Fields.

Edit Body Field. See new Tab - Translate. Click on it.

Standard field translation technique / interface. Looks perfect and the same with core translation interface. Excellent!

But I don't like one thing. Body field source language is not Bulgarian, it has to be English!

Probably due to the fact that the Bulgarian language is set as the default in admin/config/regional/language - I forgot this, usually this is my default setting for monolingual sites.

Make changes:

I go back to the edit of the Body in Page Content Type field. Nothing has changed

What to do? I return to the language page and delete the Bulgarian language.

I go back to the edit of the Body in Page Content Type field.

There is no Bulgarian language anymore, but the Body field is "not translated"

I check various settings and find the page

admin / config / regional / translate / i18n_string

I decide to try Refresh Strings first. Click it.

I check various settings and find the page

admin/config/regional/translate/i18n_string

I decide to try Refresh Strings first. Click it.

Nothing changes, Body field remains untranslated.

Back again to admin/config/regional/translate/i18n_string

В Select text groups I mark check bock Fields

Message:
The string field: body: page: default_value for textgroup field is not allowed for translation because of its text format.

Message:
This string uses the Full HTML text format. Strings with this format are not allowed for translation.
Text format: Full HTML

Searching again, find

admin/config/regional/i18n/strings

Activate Full HTML. The forms ask me for Source language - I mark English.

Back again to

admin/structure/types/manage/page/fields/body/translate

Hooray! The Body field is now in English (source)!

OK, I go back to admin/config/regional/language and add Bulgarian language again.

Back again to

admin/structure/types/manage/page/fields/body/translate

Start translating Body in Bulgarian ...

Works OK!

To check, go to admin/structure/types/manage/page/display/default and temporarily enable Body Label = Above

It works!

("Основен текст" in the screenshot is the Bulgarian translation of "Body")

I do a second check for Field Translation, create a Gallery field in Page content type, which uses Colorbox and is outside the standard fields that come with Backdrop.

In this test Field Translation works OK again:

Summary:

Field translation works great so far with the fields created by the system and with custom fields. I do not know how it will behave in the fields created by a specific module, on the same site I will install Ubercart later and post if there are problems with this module specific fields translation.

Experienced Drupal users will be able to handle the settings in i18n, novice users will be helpless in what order to properly set up the system without a good tutorial or guide.

In this test the system is completely stable, I do not see any errors, bugs and problems.

For myself, I conclude so far that the smoothly working with other modules i18n (I have so far tested only Field translation) when developing a multilingual site should be installed immediately after installation of the system and any settings related to a language other than English should be done AFTER the installation of the necessary corresponding module from i18n.

Field translation is a must when developing multilingual sites (I've been dealing with custom field templates, so far), so I'm including i18n in my Backdrop tools arsenal as of today even before official release.

Thanks to everyone who made the effort to update i18n for Backdrop. I will continue to report here my experience with the other i18n submodules - I hope this is useful and not annoying for readers.

Some term translation/selection handling might go into core

Issue: backdrop/backdrop-issues#4774

Keep an eye on it and check, which changes might be needed in i18n_taxonomy.