I need to add "ru" content localization. So I changed the following fragment:
<localizations>
<localization language="ru" default="true"/>
</localizations>
Then I ran the following command:
php bin/adminconsole sulu:document:initialize
After that, I replaced all the values of a "lang" attributes from "en" to "ru" in all xml-files inside config/templates/pages directory.
But all pages in the administration interface now have empty labels.
I tried changing the value of the "System Language" field in the permissions tab of the contacts to "English". I also reverted all xml-files inside config/templates/pages directory (from "ru" to "en"). Thus the fields become displayed.
So how can I add Russian localization in the "System language" field to solve my problem?
Sulu Core Developer here 🙂
What you have added is another content language, which describes in which languages the page, media, articles and so on can be translated. These languages also appear in the dropdown on the very right of the top toolbar.
However, this language only is about the values the content manager is filling into the fields. All the labels, navigation items and other texts that appear in the UI are displayed based on the system language of the user. Each user can choose their system language in the profile overlay, which will be shown when the name of the user is clicked on the left navigation.
So in order to see the ru titles you have added to the page XML files, the user needs to choose ru as language.
Unfortunately this language does not exist by default in Sulu. So what you can do is to add this language using the configuration in config/packages/sulu_admin.yaml.
sulu_core:
locales:
en: English
de: Deutsch
ru: Russian
translations:
- en
- de
- ru
Afterwards you can download a language using the sulu:admin:download-language command:
bin/console sulu:admin:download-language ru
This will try to download the russian language from our Crowdin Project, which is a crowdsourced translation platform. But I am sorry to say, that the russian translation does not exist there yet. If you want to contribute it, let us know, and we will create the russian language, so that you can start translating it.
If you really just want to add russian titles to the labels, you can still write the YAML configuration as above, and you will see them, when the user chose russian as their system language. All the other texts will fallback to english in that case.
Related
I have a Drupal 9 website with an Opigno distribution.
Opigno LMS has the following structure to learning: Training > Courses > Modules > Activities (ex. Quiz, or a YouTube video). I have structured my website as follows: Each Training has many Modules. Each Module has many Activities.
Opigno LMS has a feature called the Documents library. This allows the administrator to “add files” to a Training. This is likely to be reference materials for students.
The Documents library utilizes a Drupal module called Taxonomy File Tree (TFT).
The Admin can alter what “add a file” looks like by:
Go to “Structure” > “Media Types” > “File” > “Manage Fields”
Click “Add field” for a new, desired input field when “adding files”
Click on “Manage form display”
Edit the visible fields to insure your new field is added to the visible form
This works effectively, but there is one last step that is missing:
When one tries to alter what the “Manage Display” looks like, we see that everything is either “Disabled” or “- Hidden -” clearly indicating that the display of the files that are added are being controlled elsewhere. I tested this by attempting to enable the fields in the “Manage Display” section, only to see nothing was altered at all in the appearance of the files.
“Manage Display” typically is what would be used to determine what the list of the files from the “Documents library” would look like; However, that is not the case here. I am unsure where the “Manage Display” is being overwritten.
**Any ideas of where to look or where this functionality exists?
**
What am I trying to change:
I want to remove file uploads and replace them with a Link to a file that is being hosted elsewhere.
This provides a much more seamless experience internally as our documents are updated regularly, but our links to the documents do not change. (prevents uploading new documents each time there is a minor change)
I am able to add the Link using “Add field” and “Manage form display”; Additionally, When clicking “add file” using the native “Documents library” it does successfully add the file.
I am not able to see the Links I just added in the displayed “Documents library” files (“Manage Display” issue described above)
I am able to find all of the uploaded files using “Documents library” (.pdf, image, etc.) “Content” > “Media” > “Files”
*I am able to find all the Links added using “Documents library” (Link) “Content” > “Media”
The file path to these Links does not show up here.
What I know:
The contrib module opigno_group_manager (web/modules/contrib/opigno_group_manager) definitely communicates to the module tft (Taxonomy File Tree)
Tried looking in the opigno_group_manager code, but haven't been able to find the code that makes the change to the view.
I'm testing the Django CMS and I'm looking for a way to create the pages one time for all languages. Currently I have to create a new page for each languages and the content/plugin/structure is not shared between the different languages.
Is there a way to achieve this?
Thanks in advance
The built-in management command ./manage.py cms copy lang copies the entire page tree from one language to another. The page tree stays unchanged and the plugin trees are transferred. That is fine if you want to bootstrap a new language for the entire site.
If you want to copy the plugin trees for only one page, you can use the language menu from the toolbar: Language -> Copy all plugins if you are viewing the target language. This is fine, if you only have one page.
If you want to bootstrap a language for a page tree, i.e. a page and all its children, then you either have a lot of clicking to do, or use this short management command I created based on the original DjangoCMS ./manage.py cms copy long command. It allows to specify a page to copy either by its id or by its name in the source language (attention: it has to be unique).
Copy this snippet into any of your application's command folder: my_app/management/commands/. Once you've copied the file you'll have a new Django management command available: ./manage.py copylang. Usage examples:
./manage.py copylang --from-lang=en --to-lang=nl --tree="Home"
./manage.py copylang --from-lang=en --to-lang=nl --tree_id=36 --force
The page id needed for the --tree_id option can be easily inferred from the page admin by hovering over the page's preview icon. The page id is part of the link: .../page/page_id/lang/preview/...
If you leave out the --treeand the --tree_id options the command will revert to DjangoCMS's original cms copy lang behaviour.
The management command provided by #Fabian is quite useful.
I updated the command code here to reflect the changes in django-cms API:
# pages = [head] + list(head.children.drafts())
pages = [head] + list(head.get_child_pages().drafts())
Tested against django-cms 3.5.3 and 3.7.4.
All credits go to #Fabian.
We have an application built on Symfony-CMF which is running fine. We now have a requirement to add locales and translations to the content. We have set up one page (/contact) with various locale specific routes (e.g. /en/contact and /fr/contact) and we are able to visit those URLs and edit the content for each language independently. However, we are not able to see the existing content so when we hit /en/contact all the editable content areas are blank.
By rebuilding our app and loading the content (via fixtures) with the relevant multi-lang config in place, we are able to see the original content in place but when we edit it, it seems to edit it for each language. So when we go to /en/contact and edit the content there, we see that change reflected at /fr/contact and vice versa.
We have added the following config:
doctrine_phpcr:
odm:
locales:
en: ~
fr: [en]
de: [en]
cmf_core:
multilang:
locales: [en, fr, de]
We have BasicPage class for our documents:
/**
* #PHPCR\Document(referenceable=true,translator="attribute")
*/
class BasicPage extends Page implements SeoAwareInterface, SitemapElementInterface
{
/**
* #var string
* #PHPCR\String(nullable=true,translated=true)
*/
protected $intro;
...
}
Is there something else we need to do to make the original content translatable?
how do you load the fixtures now? do you use bindTranslation to store content in multiple languages? otherwise you will only create one language version of the content.
when editing, the language you load the document in is the one you store back to, unless you explicitly specify its a different language. (usually, you would change the field that is mapped to the locale of the document).
in your case, if the document is only translated to english currently and you ask for the document in french, phpcr-odm will fall back to english and give you that document. you then edit that and save it back, updating the english version. best is mapping the locale on a field and either expose it to the editor for explicitly specifying the locale or use a content language parameter in the url to avoid confusion.
you can ask the document manager for available translations as well, if you want to show that information.
by the way, we are currently working on providing a tool to convert non-translated documents to translated documents and vice versa: https://github.com/doctrine/phpcr-odm/pull/655 . if you want to check this out, feedback is highly appreciated.
Ok so I managed to figure this out myself (partly due to the info provided by dbu and partly thanks to xdebug!) The cmf_create inline editor was generating ajax requests to update the documents but these were using the default locale rather than the locale specified in the request. Setting cmf_create.rest_force_request_locale to true as specified in the CMF docs worked and means we can edit each language separately when loaded from our fixtures. We still need a migration to make each document translatable but we may be able to leverage the converter tool as mentioned by dbu.
I have a big problem with the language switcher,
I have a multi language site that has every article in english and spanish , spanish being the default
so if one article is named :
domain.com/mi-articulo then the english one will be domain.com/en/my-article (using autopath is creating these aliases)
now this works fine if I manualy change the url.. but if I use the language switcher ..the english corespondent it's switches without aliases and Lang prefix
so instead of domain.com/en/my-article it finds domain.com/node/47 so as I have the menu and other things translated it makes drupal unaware of the language switched..
here are the screenshots to better understand what's happening (wierd behaviour)
ver1. spanish
ver2. english
now if i click on english ..look what happends (see url and content like drupal is not aware that this content is nor spanish nor english...because the language switcher doesn't find the aliases)
I had the same problem until I set the default 'Language domain'
in admin/settings/language/edit/en. Now the module is working as expected.
I stumbled upon the same issue today.
All nodes had been imported from another site. All translations were imported, but not the relationship between them, so if you edit a node and check the translations, you may notice that your node doesn't have any given translation.
If this is your issue, you may use the functionality to add existing nodes as translations.
I have the same problem with the language switcher; just cannot get it to do what it's supposed to do. I ended up effectively writing a very simple version of it by adding a block and inserting the following html:
<ul>
<li class="first en">English</li>
<li class="last fr">Français</li>
</ul>
It is limited in that it always takes you back to the homepage after a switch but once that's done, links to other nodes continue correctly with /fr in the url.
I've read that using the t('text to translate') I can translate texts in drupal templates. The problem is, this function doesn't do anything. It simply outputs the same text.
I already have a site and I have installed the proper modules so that's not the problem.
I am using this to translate the titles for the blocks in block.tpl.php.
<h2><?php print t($block->subject); ?></h2>
So this outputs the same original text i'm defining in the title of the view as the block. Why? If I had an error shouldn't Drupal output something or log that error at least?
Translation is not magic. You also need to set up the language of your site in something else than english and be sure that the string you display have a translation.
You can check this at this page : exemple.com/?q=admin/build/translate/search (d6 url)
for the t function to work, you have to do the following:
enable the optional core modules called locale (for interface items) and optionally the content translation (for content).
grant the proper permissions for the proper roles
go to site building -> translate interface to access the interface translation page.
hope that helps
-peter
The translation is not being displayed because its not there. You need to add the translation of that particular string, only then the translated string would be rendered. If you have all the required modules in place, then you need to go to "admin/config/regional/translate/translate" and then search for your string; then click on edit and add the translation of that string.
You also need to install the Locale module and provide translations in the languages you want to support.