I want to make my site supporting both LTR and RTL languages.
What I want is, if text loaded in some element is RTL then switch direction to RTL. Also for inputs, when user type text, it should trigger if it's RTL and change direction to RTL.
Like Facebook is doing it for example. If you type some Arabic text in search it will automatically switch direction to RTL
Didn't found any practice tutorial by googling, any script or so.
I only found attribute dir="auto" which automatically triggers correct direction but looks like this it is not supported with older Browsers.
Any advice, tutorial, script how to do this would help.
If you only want to support switching the textbox context from LTR to RTL when the user types, then you will have to listen to the input events (input, keypress, keydown, etc, whichever works best for your case) and let the code decide whether the textbox is LTR aligned or RTL aligned.
You should note, though, that the algorithm for this is not all that straight forward, and that different products work differently. A few examples -
Facebook uses an algorithm that, for the most part, tries to recognize the first "strong" character, so typing a sentence with one Hebrew word followed by a lot of English will still show the paragraph as RTL aligned. (They also seem to have a difference between what you see when you type and what you see when the comment is posted but that's a different issue)
Google hangouts seems to switch its RTL/LTR contexts based on the number of strong characters in each direction. As you type, your context may switch several times from LTR to RTL if you start typing one language over the other.
There is no right or wrong here, there's only preference and what works best as your algorithm.
You can read about "strong characters" in the Unicode Bidirectional Algorithm here: http://unicode.org/reports/tr9/
You can see an example of how to recognize the first "strong character" in a string for embedding purposes in MediaWiki's language file, with the regex that tests directionality (group 1 is LTR and group 2 RTL) You can use these to create a JavaScript method that sets your textarea's dir="" attribute based on either the first strong character or the majority of characters, as you see fit:
https://github.com/wikimedia/mediawiki/blob/6f19bac69546b8a5cc06f91a81e364bf905dee7f/languages/Language.php#L174
As a side note, I will just point out that supporting RTL/LTR online is not just about typing and textboxes. Changing between LTR and RTL contexts also involves UI adjustments, like mirroring the alignment of the content and/or the positions of things like menus and the logo.
This is relevant if you want to allow your page to be translated to an RTL language, which means you will need to also mirror the layout. If your only goal is to switch contexts in the textbox, you shouldn't worry about this, but if you want to make sure the site allows for translation, you need to consider methods of mirroring your UI and your entire interface.
Related
I have an input field for credit card number and I want to achieve a different behaviour from the default place holder.
My place holder is more of a pattern: "xxxx-xxxx-xxxx-xxxx" and I want that in every number entered only the specific x's will be written over and the rest of the placeholder will remain intact(each preserves its own color).
I have seen this post which suggests the use of mask and jQuery but I prefer solutions that combines html, css and angular instead.
If it helps there is an illustration:
What you are looking for is called an input mask. It is unfortunately not a feature of HTML, but you’ll find plenty of libraries and questions on Stackoverflow (:
What is difficult is finding a good one that is
working with copy & paste or autocomplete
using number-optimized on-screen keyboards
not messing up the number when correcting a character in the middle
works well with assistive technology, which users with disabilities rely on
That’s why credit card inputs that work really well do not use input masks on the web.
Usually their implementation follows this principles:
The original input is broken apart into inputs and static text (the placeholder)
Styling is removed from the inputs
Everything gets wrapped in an element that then is styled like an input
Text is styled in a way to align flow of static text and input text
Write a lot of JavaScript to implement behaviour like a single input
I encountered a strange display of punctuation within DIV elements. In my HTML the text is something like:
This is just some
random text...!!
But in the browser window, it systematically becomes:
This is just some
!!...random text
I am using the code from IntroJS, and I wonder if this has to do with default formatting of right-to-left languages (such as Persian or Arabic). I am guessing this because also trying to select the text from the DIV only works when clicking top right to bottom left.
Point is, I don't know how to remove this formatting or setting in order for punctuation to display correctly in English.
Anyone encountered this before?
See if any of your CSS has direction: rtl. If your intention is not to support RTL, then removing this should fix the problem.
If you do need to support it, then I recommend this excellent (but long!) article: http://moriel.smarterthanthat.com/tips/the-language-double-take-dealing-with-bidirectional-text-or-wait-tahw/
TLDR: the reason your punctuation changes order is due to the weak directionality of certain characters... and it's a right PITA when dealing with multilingual sites that mix LTR and RTL!
I using JasonDavies's Word Cloud for my project, but there is a problem that I using Persian[Farsi] Strings and my problem here that words have overlapping in Svg.
This is my project's output:
What happened to the Farsi words?
As explained on the About page for the project, the generator needs to retrieve the shape of a glyph to be able to compute where it is "safe" to put other words. The about page explains the process in much more detail, but here's what we care for:
Glyphs are rendered individually to a hidden <canvas> element.
Pixel data is retrieved
Bounding boxes are derived
The word cloud is generated.
Now, the critical insight is that in Western (and many other) scripts, glyphs don't change shape based on context often. Yes, there are such things as ligatures, but they are generally rare, and definitely not necessary for the script.
In Persian, however, the glyph shape will change based on context. For non-Persian readers, look at ی and س which, when combined, become یس. Yes, that last one is two glyphs!
The algorithm actually has no problem dealing with Persian characters, as you can see by hacking the demo on the about page, putting a breakpoint just after the d.code is generated, to be able to modify it:
Replacing it with 1740, which is the charCode for the first Persian glyph above, and letting the algorithm run, shows beautiful and perfectly correct bounding boxes around the glyph:
The issue is that when the word cloud is actually rendered, the glyph is placed in context and... changes shape. The generator doesn't know this, though, and continues to use the old bounding data to place other words, thus creating the overlapping you witnessed. In addition, there is probably also an issue around right-to-left handling of text, which certainly would not help.
I would encourage you to take this up the author of the generator directly. The project has a GitHub page: https://github.com/jasondavies/d3-cloud so opening an issue there (and maybe referring back to this answer) would help!
I'm drawing texts on the screen letter by letter.
In English it is very simple, because the text is LTR so the letters are saved in the String in the same order they're shown.
When drawing RTL text than I need to switch the direction of the printing. but when there are letters and numbers and English and some RTL language.. than the mess starts.
For Ex.
ex.1: שלום לכם
ש- is the first letter in the string - but as we can see that it shown the last
ex.2: שלום to all
ש- is the first letter in the string- but as we can see that it is shown in the middle, before the English starts.
It is getting more complicated when numbers and math signs are getting into the picture, and special characters like '(', ')' that needed to be flipped...
Found many Bidi algorithm online that changes the logical order of the letters in the string to visual one. So when i run from left to right on the converted string i'm sure that the string will print properly.
BUT,
They are never perfect. There are cases that they are not working properly.
None of them considering the direction of the text as well (means when we press the right Ctrl+Shift on the keyboard than the visualization is changed again)
My questions are
does anybody know some bulletproof Bidi algorithm i can use to change the string from what it saved in the memory to visual order?
Is there a simpler way to solve my problem ? maybe somehow get the browser algorithm for it..
After searching for long time,
I've found that DOJO (and luckily it is the tool kit that i'm using),
has has a BIDI engine for drawing it's own UI controls, that gets few layout parameters to handle some cases of RTL, LRT, and contextual directions as well.
If this is helping someone -
http://bill.dojotoolkit.org/api/1.9/dojox/string/BidiEngine
Found another link that might help to a none DOJO developers -https://github.com/ibm-js/dbidi, but I have not check it yet
How can I make a right-to-left and up-to-bottom textfield for user input in a browser? Are there any native ways to do it? Or maybe workarounds?
(Up-to-bottom could be like Japanese, or the hieroglyphs.)
For RTL text field, you can use the HTML dir attribute (like Šime Vidas has already mentioned) or the with dir="RTL" direction attribute in CSS with direction: rtl. You can use these properties on most visual HTML elements, not just on text fields.
As for top-to-bottom direction, there's no easy standard method that I am aware of, but that's OK, since Japanese web pages rarely use vertical text that's not embedded in images or Flash objects, and I've never seen any site using vertical input. In fact, vertical input in Japanese computers is rare extremely rare even outside of HTML, and is usually found only in WSIWYG editors (such as Word Processors) that produce printed vertical text.
There's also an automatic javascript that flips ltr to rtl automatically:
https://github.com/urigoren/RTLjs