I have three languages on my website English, French and Spanish. Either the translation is disabled in the paragraphs, then all languages are displayed as English (is also correct for me in some cases) or I enable the checkmark: "User may translate this field" in my paragraphs. But then I always have to adjust all three language contents.
Is there also a possibility, that it copies with the checkmark activated equal the English first of all as contents into all three languages and I then adapt the languages, which I can adapt also really as language.
At the moment, I then always pfege all three languages. In the worst case then three times the same content in English. This makes it of course very cumbersome?
Does anyone of you know the problem and is there a solution for it. Have I overlooked something in the configuration of my paragraphs.
I am using the latest Drupal 9 and the latest version of Paragraphs.
Thanks a lot
Bavra
Related
Suppose you're developing a web site and blind users will be a significant chunk of your target market. If the web site includes document editing functionality, what would be appropriate WYSIWYM tools? Are languages like Markdown, Textile and Wiki Formatting really accessible or are they inconvenient to blind users?
I'm a blind programmer and while I haven't used most of the languages you mention I've found that any markdown language is fairly easy to use if you have the desire to learn it. I've had no problem using either HTML or several markup languages for wiki's. Part of it will depend on how invested the users are in your site. If it's a site that will be visited infrequently or for short periods of time, it's much less likely that a user will take the time to learn the required markup whether they are blind or not. Unfortunately, I have not found an accessible JavaScript WYSIWYG editor but I find it easier to manually enter the markup so haven't looked very hard.
the first question is: how important is semantic structure? could you get away with plain text. You could do simple parsing like treating blank lines as paragraph markers, treating a series of lines which begin with * as a bulleted list, identify URLs and make them into links, etc.
As a blind developer myself, I have no problem in understanding languages like Markdown. But if it's a syntax I'm unfamiliar with, I'll only learn it if I expect to use the site very often, or care deeply about the content.
Two final thoughts come to mind: while I certainly experience some accessibility challenges using TinyMCE, you could develop something much simpler - provide less than 10 formatting options, like inserting hyperlinks, making lists, centering text, setting the style (such as heading) etc.
And lastly, when I talk to non-technical blind people, they often just write their content in Word and paste into a wiki or blog post. This sounded strange when I first heard it, but it does make sense. So an ideal solution would accept pasted in content.
In closing - it depends how important this is, and how much effort you want to expend. Maybe a Markdown editor with a live preview (like on this site), buttons for inserting simple formatting like URLs, and the ability to paste in rich text would tick all boxes :-)
On a web page, the most accessible embedded text editor for blind users is one that uses standard HTML, such as a <textarea> element, with a corresponding <label> element:
<label for="editor">Enter your text here using wiki markup:</label>
<textarea id="editor"></textarea>
If a WYSIWYM tool is built using standard accessible HTML, then blind users can easily enter text into it, with full confidence that they're entering text in the right place. Then the question becomes: Which is the better markup language? They all require memorization, but some may be more intuitive than others. One way to find out which is best would be to do some usability testing with a wide variety of target users. Also be sure to providing easy, accessible access to syntax help.
Picture yourself working in pure text 80x4 display (just open a console and resize appropriately), then use vi/emacs/ed and you'll soon realize what markup will get in the way.
Try to do as much work as possible to understand plain text, else use light markup like POD, finally things like AsciiDoc are very powerful but needs training.
I don't know about WYSIWYG/WYSIWYM tools, but I do know that complying with W3C standards (especially their HTML5 en CSS3 drafts) while writing your own editor code will help a lot.
In CSS you can specify speed and intonation of speech. In HTML you can specify alternative text (alt attribute in many elements) that screen readers are compatible with. Be sure to know when to use the abbr and the acronym elements. Use the former when you want the screen reader to read the meaning of an abbreviation and the latter when the acronym should be read as a word (e.g. ASAP, NATO and OS).
For the editor itself, I recommend creating a WYSIWYG editor that uses divs and spans. Screen readers will understand easily the structure of a document. For the current line, use a text box; for every other line that's not being edited, convert the contents immediately to valid HTML.
If you find a good tool, be sure to post it here. I'm looking for one too. :-)
We have a Plone site that is primarily in English but has some content translated to French, and to a smaller degree had some pages originally in French and translated to English. In Plone 3, this has been working fine.
In Plone 4, a user whose language is set to "fr" can see virtually nothing - only those pages with a translation to French.
If we run ##language-setup-folders it gets worse - now anything that is defined as "language neutral" is invisible to English users too.
Surely, the intended behaviour is that a user whose language is set to English will see folders in "/Plone/en/...", and a French user will see "/Plone/fr/...", but if the page is not found it should fall back to /Plone. This is not happening.
Should it?
If so, under what conditions?
The language-neutral thing is a known bug, I believe. As to the fallback: as I understand it, the current behaviour is as follows: if you switch from en to fr and the current object does not have a fr translation the user is returned upwards towards the site root until there is a fr folder. (Or the root is reached.) No, I don't think that makes too much sense either, but at least a fr user will never see an en page. ;)
If you run ##language-setup-folders, you intitiate a setup that assumes that all content lives in the content-specific trees. The language folders are marked as INavigationRoot and will have the navtree and all anchored to the language folder.
You should basically assume each language to act as its own site with its own root.
— Except that translation management will keep "links" between translated versions of content and folders.
LinuaPlone only supports "full translations", that is, for every article there must be a translation. Very bad for many use cases where you only have one main language and only a subset of all articles actually needs to be translated... :(
You should have a look at http://plone.org/products/raptus.multilanguageplone (and its dependency http://plone.org/products/raptus.multilanguagefields). These addons do what you want :)
You can still make items language neutral. And this way they can still appear in the site of the other language via a collection.
I think setting items to Language Neutral used to work via "manage translations", but now it still works via:
Edit > Categorization > language
Select language neutral
I'm really stumped here.
I've created a page with 3 languages, but the language switcher will not work properly.
I have translated both the menu entries and the content, and I want to use the language switcher to change both the menu item language and the content language.
What is happening now:
The language switcher points the browser to the node with the content translated, but the menu items are not working.
Or more exactly, the are for english, not russian.
I have in total 3 languages: Latvian, Russian and English, with Latvian as default. When I create some content in Latvian and the corresponding menu items, all is well. When I translate it into English, and add the menu items for English, all is well too, but the prefix for the link is not added. Since I'm using PathAuto, I believed, that that the language switcher would be using the newly generated node alias, but it is not. It is simply pointing to the node in English. But that is not the worst part.
When I select Russian, the content is translated, but none of the menu items appear. Also, sometimes, the prefix is added for russian, and then I can't revert back to Latvian, since there are no prefixes added for the default language, and the node alias is not displayed, only the node ID.
Any Ideas of how could I fix this? It is the only thing standing between me and completion of a project.
P.S. It almost seems, that Drupal was not made for this kind of a thing.
P.P.S I solved the problem for 2 languages - renamed English to Russian, since the client doesn't need English right now. I know, short term fix, but otherwise, my whole work would be in ruins.
Just in case someone else has a similar problem.
I fixed the language switcher issue by adding a path prefix for english.
My site's default language is spanish and I have english as a second one. I Installed everything, add the english prefix and followed the instructions of this site: http://openflows.com/blog/mvc/2008/10/03/drupal-6-i18n-basics
the prefix issue is discussed here: http://drupal.org/node/354069
Hope this helps
You can easily add the prefix for your languages by going to /admin/settings/language/edit/en
I had the same problem and this saved me the hassle of going and fixing it from the template.
The problem was in the template I was using. It rewrote all of the url's for beauty purposes, but didn't add prefixes correctly.
I am working on a bilingual site in the latest version of Drupal 6. I installed the Internationalization module and the Views translation module, among many others.
The problem: On /admin/build/translate/search, some elements (e.g. the view title) appear in the text group "Views" and Drupal assumes they are in German, requiring an English translation.
Other elements (e.g. exposed filter labels) appear in the text group "Built-in Interface" and Drupal assumes they are in English, requiring a German translation. But in fact all the strings are in German:
To be clear, I am not seeing an issue with the language selection or the display of the view. The issue is when the page is first parsed by the language system and any translatable strings are inserted into the translation table. Drupal assignes different source languages for elements on the same page. The result is a mix of languages, once these strings are translated.
I thought that maybe it is the language preference of the user who hits the page first that interferes with this, but once I started changing it, I ran into this issue (reading the thread was eye-opening - it should be mandatory reading for anyone considering Drupal for enterprise-class solutions). Ok, now I have the URL prefix in the mix, which means that when a user changes the language preference, the site language does not change until they manually change the URL.
Once I managed to get the page rendered in English, it turned out that Drupal does not pick up the translation strings when the display language equals the source language. So no luck there.
I am ready to code my view in 2 languages, depending on what Drupal thinks the source language is for the various elements, but even that won't work. Has anybody else experienced this?
I think that you probably had basic mistake in how Drupal multilingual system work. I did the same mistake in the first multilingual Drupal site that I've built.
The most important thing to do is - if one of your languages is English - Use English in your code. if you need to put the word 'room' in one of the template use t('room') and not t('zimmer'). Your view titles? use English. Tag names and description? use English. The primary language should be English. After you setup your English site, you can translate your site using translate interface. I know it sound strange to one that his mother tongue is other than English, but I made several multilangual sites with i18n and it is the right way to do it with minimal complications.
Changing the admin interface language only change the interface - not the value. If you change the interface to German (i.e yoursite.com/de/admin/views) it doesn't mean that you are on 'German views'. It is the same view.
There are some exceptions - Multilingual variable as I explained here: How can I set a different homepage per language in Drupal?
I hope that is helpful.
I work on a collaboration web app, built with Flex 3, that needs to support multiple languages.
Does anyone know which fonts are best for creating embedded font libraries for Chinese, Korean, Japanese, and Russian languages? I know Arial Unicode MS will do the job, but I don't know if it will do the job best.
Localization alone won't solve the entire problem: chat input and display, for example, need to support multiple languages in the same textfield - anything typed in Chinese needs to display in Chinese; anything typed in English needs to display in English.
Using _sans is an option, but is far from preferred.
Thanks.
Went with an approach that switches TextFormat of characters based on unicode value. So, characters in the primary language display in the preferred (embedded) font, while characters in other languages display in _sans.
This works out really nicely, but requires that you inspect every character that is added to a field, and requires you to inspect everything when a deletion occurs. Kind of a lot of inspecting and I'm sure a textfield with a lot of content would start running into performance issues, but this is for a chat tool, so that isn't too critical of a use case.