This is also true for interface translation. In the configuration translation tidbit, we covered that there is one single flat permission for translating all of configuration. Drupal's search integration APIs are also fully equipped with language information, so third party search integrations will know about translations just as well. One option is from Administration > Reports > Status report). (If your search found no results, make sure to run cron for the indexing to happen. So if you search for "English" in my example, you'll find the English translation immediately. The core search module indexes translations separately. We covered how views are configured with language options in the blocks and views tidbit.įinally translated content is also integrated in search. Again, the front page is a view, so you can customize how it filters what it shows and what language is used to render the content it finds to display. If you view the front page in Hungarian, the Hungarian original will be displayed. So if you view the front page in English, the English translation will show up there. That would allow me to provide distinct content management and translation management screens.īut where else would the articles show up? Well, the front page is configured by default to show promoted articles in the language selected for the page. I can even clone this view/display and create a translation dashboard tab. What's really great is that this page is a view, so I can customize the content administration experience to support translators better. The list may also be filtered by language. It is possible to act on each translation individually to make them published / unpublished (which in my case is per language as is by default). Once the translation is saved, the content administration list now displays both. I have access to edit all fields for the translation as a content administrator. A subtle "(all languages)" note appears alongside the tags field. In this case, I configured the tags field to not be translatable. The translation form uses the same content editing experience and it even prefills all the original Hungarian field values. Behind the translation tab is a list of languages on the site to use as target languages.Īt this time, there is no English translation, so I can add one. For example, in this case, I am editing an original Hungarian entity (actual words in English for sake of readers). Example: translate articlesĪ translate tab would appear on content like this. Drupal can translate from varying source languages to other target languages. There is of course no requirement that the original content entity be of any specific language. The entity should have a configured language (not one of the "Not applicable" and "Not specified" built-in languages).The site should have more than one configured language.The bundle (subtype) of the entity should have translation support configured.When editing an entity, there is a set of conditions to be met for it to have translation support: The question is how does it all work then, what do we do to translate content? When can an entity have translations? Then each entity structure may be configured on the field and in some cases subfield level to support translation. In short now you can configure translatability on any subtype of any entity type, so for example articles or specific taxonomy vocabularies may be configured to have all their entities support translation. In the previous tidbit, we covered content translation basics.
0 Comments
Leave a Reply. |