Testing of i18n - Field translation

[amilenkov]

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.

[indigoxela]

A quick hint: the source language can be changed, it's an i18n setting (in D and B). Go to admin/config/regional/i18n/strings and choose which language should be the source.

The help text there: "Language that will be used as the source language for string translations. The default is the site default language."
This hasn't changed in the port.

But a word of warning: if you change that setting after you already translated stuff (like field labels), your translations will be lost.

[indigoxela]

@amilenkov Out of curiosity: what are the i18n submodules, you still see as essential? Backdrop core provides better internationalization than D7 does, but there are still some things missing.

Would you agree, that especially the field (label, description) translation is essential for true multilingual sites?
What other i18n features come to your mind when you think about missing multilingual features?

[amilenkov]

@indigoxela

I delayed my answer because I was making more tests and thinking about what to answer to your question.

I think that for simple multilingual sites that only require content translation, Backdrop is an efficient and more easier solution than Drupal 7 (without i18n).

But when a complex multilingual solution is required, for now it is necessary to add i18n to the Backdrop CMS and the combination of both multilingual support systems (Backdrop's core and i18n's) leads to confusion and clutter of the site with duplicating options.

Such complex multilingual solutions are, for example, but I do not think that this list is exhaustive:

Multilingual menus with i18n have more features and options for a comprehensive configuration;
Multilingual taxonomy;
Fields translation;
Strings translation with Drupal 7 + i18n have more features and convenience and from my five years of experience with Backdrop practical experience it works more efficiently, quickly and without unrecognized or hard-to-find strings ;

Backdrop does not have the ability (as far as I know) to translate important variables such as:

Default 403 (access denied) page
Default 404 (not found) page

The last few days I've been testing Ubercart for Backdrop and I'm glad that Ubercart is now available for Backdrop but without Variables module and i18n I don't see how I can use Ubercart on a multilingual site (but it is good for for monolingual) - there are many specific variables for Ubercart, which are easily translated with Drupal 7 and i18n, but in practice cannot be translated with the usual Strings translation method.

Just small example from my Drupal + i18n test site:

---

Select variables to be set for this realm.

Currently selected variables are: Банков превод - заглавие на метода, Bank transfer - account owner, Bank transfer - bank code appellation, Bank transfer - account bank, Bank transfer - account branch, Bank transfer - policy, Site name, Site slogan, Anonymous user, Default front page, Default 403 (access denied) page, Default 404 (not found) page, Maintenance mode message, Completion message header, Completion message for logged in users, Completion message for existing users, Completion message for new users, Completion message for new logged in users, Continue shopping message, New account details help message, Checkout instructions, Checkout review instructions, COD policy message, Check payment policy, First name, Last name, Company, Street address 1, Street address 2, City, State/Province, Postal code, Country, Phone number

I assume that this problem is also present for other more complex modules inherited from Drupal 7, which follow a paradigm involving the use of i18n (and Variables) for multilingual support.

As a result, I refused to use Backdrop for the small online store with Ubercart, which I have an order to make - I finally decided to do it with Drupal 7 + i18n - so it's much easier and faster, without unnecessary headaches. I'll convert it to Backdrop at a later stage, probably years from now.

I don't think I'm competent to make a proposal on how to solve the problems from a programmer's point of view. But I have a feeling that they will not be completely solved within Backdrop 1x because they require a complete rethinking of the approach to multilingual support, so that it is solved comprehensively at one point, rather than individual solutions to individual problems and tasks, step by step.

For example, to have a separate module for a multilingual home page, then for a multilingual 404 page, etc.

In view of all this, I think that using and improving i18n on Backdrop and finding a way to translate variables, or at least the most important ones, is important at this stage for multilingual support for Backdrop 1x.

[indigoxela]

@amilenkov many thanks for sharing your thoughts and experience!

the combination of both multilingual support systems (Backdrop's core and i18n's) leads to confusion and clutter of the site

I'd agree on that. For me that's also true for D7, but as several multilingual enhancements went into Backdrop core, the situation has actually become worse at some points - at least for me.

there are many specific variables for Ubercart, which are easily translated with Drupal 7 and i18n, but in practice cannot be translated with the usual Strings translation method

Personally, I've never used Ubercart, so I wasn't aware of those problems introduced with the lack of the Variables module in Backdrop. Many thanks for pointing me to that.

Regarding the 404, 403 and maintenance pages... Good point! I think, that really should go into core.

[indigoxela]

Oh, update, the maintenance mode message is translatable (admin/config/regional/translate/translate). Search for [site:name] is currently under maintenance.

[indigoxela]

Off topic here, but these are the steps to get a translatable 404 page:

1. Create a translatable node (type page) for that purpose and translate it
2. Go to admin/structure/layouts and add a layout, for exampe "site_404" with a static path
3. Configure that layout to use "existing content", choose your translated node from step 1
4. Important: set "Load translated version of the content if available" for that block
5. Go to admin/config/system/site-information and set the layout you created in step 2 as the 404 page

I'm aware that this should be easier, but at least it works.

[amilenkov]

@indigoxela thanks for the feedback!

Backdrop CMS is extremely important to me, and I consider for also millions of users from small businesses and NGOs around the world. For large markets in big countries whose languages ​​are world standards, multilingual aspect may not be so important, but in small country like mine - Bulgaria, the multilingual capabilities of the site are simply mandatory in most cases. If it does not support English, German, Russian, French, Spanish or at least one other popular languages ​​- a site in Bulgarian is limited to a very small market segment of users. In Bulgaria to be educated means to know at least one foreign language - most often English, or German, French, Spanish.

And I'm sure this is true for dozens and even hundreds of thousands other countries around the world.

I can also work with Wordpress and even currently support several sites made by other developers, but I do not like Wordpress at all. A person who has worked and experienced the freedom that Drupal gives simply cannot lower his level to Wordpress stereotyping in making websites and webdesign.

That's why Backdrop's multilingual capabilities are very important to me, and I'd be happy to test in-depth and share answers to any multilingual question about tests according to my experience and knowledge.

I also believe that having an online store module for small business is also key to Backdrop's CMS future success - the development of Wordpress + Woo Commerce for me is proof of this. I have read many articles claiming this, but my experience shows the same - a huge part of the market success of Wordpress is due to the availability of Woo commerce online store module.

And in an age and future of expanding online commerce & online business, online store modules will become an increasingly demanding requirement in the coming years when choosing a CMS for a (small & medium) business website.

For this reason, I believe that converting Ubercart to Backdrop is important for promoting Backdrop and I'm very glad it happened. I also wrote about this on the Ubercart issue page, but here I want to focus on the multilingual aspects.

Drupal Commerce - the other D7 popular online trading platform - I have made two sites before with it for Drupal 7 & Drupal Commerce - I think it is not suitable for small businesses and sites with a small budget, while Ubercart is currently the best available from Drupal heritage for such websites.

I also tested the Basic cart and the promising Basic cart Plus module (unfortunately its development was interrupted), but they have limited capabilities and also have serious problems with multilingualism so far - messages sent by the Basic cart, for example, cannot be translated. In Ubercart you can with editing Rules.

But a way must be found for such a module as Ubercart to be multilingual, and this I think is a must for Backdrop's wide market success. And therefore to find a mechanism for translating variables in Ubercart and probably in many other former D7 modules that need to translate variables in their interface, not just in the content of posts, pages and other nodes.

[amilenkov]

Thanks for "these are the steps to get a translatable 404 page" tip!

[indigoxela]

But a way must be found for such a module as Ubercart to be multilingual, and this I think is a must for Backdrop's wide market success.

I agree.

And therefore to find a mechanism for translating variables in Ubercart and probably in many other former D7 modules that need to translate variables in their interface, not just in the content of posts, pages and other nodes.

I also agree, Backdrop needs to provide a way to translate interface strings that have been provided via user interface - "variables". That's field labels, but also (again, thanks for pointing me to that problem!) other admin provided strings like the completion message you mentioned.

[indigoxela]

The first alpha version has been released. A lot of changes happened in the meantime, so I'm closing this issue. Feel free to open new ones, if you discover any problems. Please read the release notes for that alpha before updating.