backdrop-contrib / i18n Goto Github PK
View Code? Open in Web Editor NEWCollection of modules to extend Backdrop CMS multilingual capabilities
Home Page: https://backdropcms.org/project/i18n
License: GNU General Public License v2.0
Collection of modules to extend Backdrop CMS multilingual capabilities
Home Page: https://backdropcms.org/project/i18n
License: GNU General Public License v2.0
Issue: backdrop/backdrop-issues#4774
Keep an eye on it and check, which changes might be needed in i18n_taxonomy.
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.
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.
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.
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.
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.
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.
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.
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.
Found while testing something else...
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]
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.
This module with all submodules still relies on textgroups when importing.
In D7 there are following groups on admin/config/regional/translate/import:
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
To take advantage of core button styling, can we wrap submit buttons in an actions container? I can make a PR.
`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.
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.
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?
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).
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.)
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.
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.
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.
Related to https://www.drupal.org/sa-contrib-2020-025
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).
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).
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.
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
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.
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.
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.
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.
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.
That file is still messy and needs cleanup before even an alpha release can be considered (i18n_path_update_7000)...
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.
I noticed when translating localized terms that the description displays HTML code instead of using the CK Editor as expected. PR coming.
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).
As above. "Merged without testing", famous last words. 😄
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.
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.
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.
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.
Check compatibility with PHP 7.4+
Tests currently fail on newer PHP versions. This task has low priority, though.
Hi @indigoxela thank you for doing the initial port... here's my first feedback
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.
These modules need a migration path, as functionality made it into core (or has gone or changed significantly).
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.
While I'm starting to dig deeper into module code, I found a weird call of language_list():
Line 249 in f0c5c7e
return language_list($field, I18N_LANGUAGE_EXTENDED & $mode);
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
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).
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.
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
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:
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.