nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Forms displayed with right-left flow languages; best practice.

Migrateduser_427

Hello all,

We are in the planning process of launching TeamSite for users in Israel and at the same time will be using Hebrew as the supported language within TS.

Has any one else done this for right to left languages?
Any issues encountered doing so and how were they overcome?
Do the forms display correctly without any modifications?

Thanks.

Find more posts tagged with

Comments

Baracus

I developed a language independent TeamSite implementation which included Arabic and Hebrew. We encountered a few issues, but most were related to extended characters, and not flowing content from right to left.

1) The DCT
Within TeamSite, dealing with any language that flows right to left is relatively easy. There are no particular settings required within TeamSite to ensure characters are displayed properly -- all that matters is that content is authored using the appropriate language. If a user has an arabic keyboard, or if you copy and paste the data from a 3rd party application (word), all of the data will appear in the proper format.

2) The TPL
Applying this data to the presentation layer requires 2 specific settings.

Firstly, you want to define the direction of the data. You can do so via an html attribute or a style sheet. Either way, it's important to realize that RTL attribute values simply aligns data to the right (much like text-align would), and doesn't actually flow the data from right to left.

<html direction="rtl">

or

html {direction:rtl;}

Secondly, in order to display extended characters, you have to save your TPLs as UTF-8. I've met many TeamSite developers that are confused by character encoding, and how to display them properly through TPLs.

Web browsers require a BOM (Byte Order Mark), also known as a "signature", in order to interpret UTF-8 and display it properly. The BOM is a "hidden" (zero width, no break space) character at the beginning of a text file that tells the application to intrepret the text file as UTF-8.

For more information regarding encoding, visit http://www.unicode.org

Hope this helps, good luck.

nipper

To add to the BOM you can use something like this:

[html]

my $UTF8_BOM = "\xEF\xBB\xBF";
iwpt_output($UTF8_BOM);
use TeamSite::Config;
(my $iwhome = TeamSite::Config::iwgethome()) =~ tr|\\|/|;

[/html]

if you use a TPL

Baracus

I prefer the "FILE > SAVE AS..." approach, much simpler Smiley Happy

That being said, I would recommend Nipper's code snippet if you work on a large team. I've had my encoding blown away by developers who used their own editing tools, that didn't/couldn't save files with the proper UTF-8 encoding...

nipper

I prefer the "FILE > SAVE AS..." approach, much simpler

That being said, I would recommend Nipper's code snippet if you work on a large team. I've had my encoding blown away by developers who used their own editing tools, that didn't/couldn't save files with the proper UTF-8 encoding...

Your second point shows why you need the data. Editors are not great about adding the BOM (esp UltraEdit which I use).

I also only use stubs for TPL, so every TPL basically spits out the BOM and then does an iw-include of another TPL (kept out of the way of prying users).

ISCBorisB

Web browsers require a BOM [...] in order to interpret UTF-8 and display it properly

That is actually somewhat inaccurate. No modern browser requires BOM. You may use it but more portable
(and in my opinion more reliable, too) method to *inform* your Browser of the character encoding is to set
"charset=utf-8" in one of the HTTP Reply Headers ("Content-Type" Header, actually) or in HTML "http-equiv" Meta Tag,
see/try my example [post=110054]here[/post]

Ultimately, whether you need to include BOM into generated assets or not depends on the consuming software.
And when I have to include BOM - I never set PT itself with the BOM, it's too brittle. Besides, PT is code and code
must not have hidden elements.