Building a website in Yiddish and Hebrew: what actually goes wrong

Adding Yiddish or Hebrew to a website sounds like a translation job: translate the words, flip the text to the right, done. It isn't, because direction is a property of the whole page, not of the text inside it. Most of what goes wrong goes wrong quietly — the site still loads, it just looks broken to the only customers it was built for.

Right-to-left mirrors the page, not just the text

There are two separate switches, and they get confused constantly.

• Direction (dir="rtl") controls which way the page flows: where paragraphs start, which side bullets sit on, which side of a table holds the first column, where a checkbox sits relative to its label.
• Language (lang="he" or lang="yi") tells the browser and screen readers what language the text is. It affects which font the browser reaches for and how assistive software pronounces the words. A Hebrew page still labeled lang="en" gets read aloud as English gibberish — see our guide on website accessibility for why that matters legally as well as practically.

The direction attribute belongs on the outermost element of the page, the html tag, so the entire layout mirrors. What people do instead is set it on individual text blocks. The paragraphs go right-to-left and everything around them stays left-to-right. That is the half-finished look you have probably seen: Hebrew text hugging the right edge inside a layout still running the other way.

What breaks when you bolt RTL onto a left-to-right design

An existing design is full of instructions that say "left" and "right" out loud, and mirroring the page does not rewrite them. Padding lands on the wrong side and text jams against one edge. Arrows point backwards — next buttons, back arrows, breadcrumb separators, accordion chevrons, the mobile menu that now slides in from the wrong edge. Carousels advance the wrong way when swiped. Progress bars, star ratings, and quantity steppers fill in the wrong direction.

Not everything should mirror. Arrows and anything meaning "forward" or "back" should flip. Clocks, checkmarks, logos, numerals, and media play buttons should not — a play button pointing right is universal and looks wrong reversed. Someone has to make that call icon by icon. No tool decides it for you.

The modern fix: logical properties

Modern CSS — the language controlling how a page looks — has replaced "left" and "right" with "start" and "end." Instead of margin-left you write margin-inline-start. In an English page start means left; in a Hebrew page it means right. One rule, both directions, no duplicate code. Every current browser has supported this for years.

The consequence is financial. A site built this way from day one adds a second language cheaply. A site built the old way needs a second stylesheet flipping hundreds of rules, and every future design change has to be made twice.

English words, prices, and phone numbers inside Hebrew

This is the problem nobody warns you about, and the one that makes a site look amateur to a native reader.

Every character in Unicode carries a direction. Hebrew letters are strongly right-to-left, Latin letters strongly left-to-right, digits are weak, and punctuation, spaces, and symbols like $ and parentheses are neutral — they take the direction of whatever surrounds them. The browser applies a standard set of rules, the Unicode Bidirectional Algorithm, to settle the final order. Usually it gets it right. It fails at the boundaries:

• A price written as $24.99 in a Hebrew sentence can render with the dollar sign after the number. For a grocery listing dozens of prices, that is dozens of small wrongnesses.
• A phone number in parentheses, like (845) 587-0531, comes apart — area code at the wrong end, parentheses reversed.
• A period at the end of a Hebrew sentence that ends with an English brand name jumps to the far side of the line.
• A product code like KG-1420 renders number first, letters second.
• A Hebrew name and an English name on the same line of an order list swap places, so your packer reads the wrong customer.

The fix is bidi isolation: telling the browser "this chunk is its own island, work out its direction separately, and don't let it renegotiate with its neighbors." In HTML that is the <bdi> element, or dir="auto" on anything a customer typed — names, addresses, review text. In plain text, where there is no HTML, invisible Unicode isolate characters do the same job.

Fonts: the failure that happens silently

Most beautiful Latin webfonts contain no Hebrew letters whatsoever. When the browser hits Hebrew in a font that has none, it does not warn anyone. It silently substitutes whatever Hebrew font is installed on that device — one thing on a Mac, another on Windows, another on an Android phone. So the designer approves the mockup on a Mac and half your customers see a different typeface at a different weight, sometimes with line spacing that jumps because the substitute has different vertical measurements. This is the most common reason a Hebrew page looks cheap without anyone being able to say why.

Choose a family that genuinely covers both scripts, and check it on real devices. Free options with real Hebrew coverage include Noto Sans Hebrew and Noto Serif Hebrew, Heebo (drawn to match Roboto's Latin letters, so mixed English and Hebrew sit together properly), Rubik, Assistant, Alef, and Frank Ruhl Libre for something traditional. The Culmus project's free Hebrew fonts handle vowel points and cantillation marks better than most.

Three type facts that surprise people:

• Hebrew has no capital letters. If your design uses ALL CAPS for buttons, navigation, or labels, that hierarchy simply disappears. Use weight, size, or color instead.
• Many Hebrew fonts have no true bold. The browser fakes it by thickening strokes, which fills in the small openings inside Hebrew letters and turns bold text into a smudge at small sizes.
• Hebrew has no italic tradition. Browsers fake it by slanting, which looks foreign. Use a heavier weight.

Nikud, te'amim, and line height

Vowel points sit below the letters and cantillation marks above, making a line physically taller. Tight line spacing clips them: if a heading has a fixed height, or line height was tuned for English, the tops of the marks shear off. As a rule of thumb, Hebrew wants noticeably more line spacing than English — where English sits comfortably at 1.5, Hebrew reads better nearer 1.7 or 1.8, and pointed text needs more again. Hebrew also reads small at the same nominal size, because there is no mix of tall and short letters to give the line texture, so a size bump usually helps.

The part that bites seforim stores: search breaks on nikud. A vowel point is a separate invisible character attached to the letter. Customers type the letters with no points, so if your product titles are stored with points, search finds nothing. The same applies to geresh and gershayim, which customers type as ordinary apostrophes and quote marks. The fix is to strip those marks from both the stored text and the search query before comparing. If you sell seforim online, ask directly whether search is normalized this way. It usually isn't.

Yiddish is not Hebrew

Yiddish uses the Hebrew alphabet but is a different language, with its own language code (yi), its own vocabulary, and more than one accepted spelling system.

The YIVO standardized orthography is what dictionaries, academic sources, and most machine translation are trained on. It is not what heimish publications use. The traditional orthography used in Williamsburg, Boro Park, Monsey, and Kiryas Joel differs in visible ways, and YIVO spelling reads as foreign and slightly academic to your customers. It is the written equivalent of an accent.

• Machine translation reads wrong. Not merely stiff — wrong register, wrong spelling system, and full of coined Germanic words for things the community says in English. Nobody asks for "delivery" in an invented Yiddish word; they say delivery, written in Hebrew letters.
• Search matching is harder than it looks. Yiddish has single Unicode characters for its double-vav, vav-yod, and double-yod combinations, and the same combinations can also be typed as two separate letters. They look identical on screen and are completely different text underneath. Pointed alefs cause the same mismatch. Normalize both the stored text and the query, or customers will search your site and be told you don't stock something you do.
• Don't justify Yiddish text. Browsers have no hyphenation dictionary for it, so forcing both edges straight produces huge word gaps. Leave one edge ragged.

Related, for your English pages: customers search in heimish transliteration. They type cholov yisroel, kashrus, shabbos, sukkos — not the modern Israeli spellings. Write the way your customers write.

The parts everyone forgets: forms, checkout, and email

Page text gets translated. These almost never do: placeholder text inside form fields, button labels that live in a plugin rather than a page, validation messages like "This field is required," the order confirmation email and shipping SMS, the 404 page, and the empty-search page.

Some of it you cannot translate at all. The browser's built-in validation popup uses the browser's language, not your site's, and native date pickers render in the browser's locale. If the language of those matters, the form has to do its own validation and show its own messages.

Two field-level details worth insisting on. Phone, email, and website fields should be forced left-to-right even on a right-to-left page, or the cursor and punctuation behave bizarrely as the customer types. And a typed name should carry dir="auto" so Hebrew and English names both display correctly in your admin order list.

Two platform realities. Payment providers generally offer a Hebrew checkout but none offer Yiddish, so your final screen will be Hebrew or English regardless — worth knowing before you promise a fully Yiddish store. And on WordPress, the admin and WooCommerce have mature Hebrew translations while Yiddish coverage of plugin strings is thin, so some customer-facing text falls back to English unless translated by hand.

Two languages means two sets of URLs

For search engines and for AI assistants reading your site, each language needs its own real address that can be linked, bookmarked, and crawled.

Each version should carry hreflang tags — small pieces of code saying "this page has an equivalent in this language, at this address." Two rules people get wrong: the references must be reciprocal (if the English page points to the Yiddish page, the Yiddish page must point back, or search engines ignore both), and each page should also point at itself. Declaring an x-default version tells search engines which page to show a visitor whose language you don't support.

Why auto-translate widgets are the wrong answer

A drop-in widget that translates the page in the visitor's browser is tempting: free, ten minutes. It fails for search. The translation happens after the page is delivered, so there is still one page, in one language, at one address — nothing new to index and no visibility in the second language at all. The output reads wrong to the community, which can be worse than plain English. And publishing large volumes of unreviewed machine translation is treated by Google as low-quality automated content, which can drag down the rest of your site.

Fewer pages, properly translated by a person, beats a whole site translated by a machine. A grocery with four genuinely Yiddish pages — home, how delivery works, ordering for Shabbos, contact — is in better shape than one with forty machine-translated ones.

Switching language without losing your place

The most common mistake in the whole category: the switcher dumps everyone on the homepage. A customer four scrolls into a product page clicks the Yiddish link and lands back at the top of the site. Most don't click it again. A correct switcher links to the equivalent page, and when there genuinely isn't one, says so rather than pretending. Beyond that:

• Label each language in its own script — English, עברית, אידיש — so a visitor who can't read the current language can still find the switch.
• Never use flags. Flags are countries, not languages. There is no country for Yiddish, and an Israeli flag is the wrong symbol for a Hebrew-reading customer in Monsey.
• Don't auto-redirect by browser setting or location. It traps people who wanted the other version, breaks shared links, and since search crawlers mostly visit from United States addresses, a location-based redirect can hide your other language versions from search entirely.
• Remember the choice in a small preference on the visitor's device. That is functional, not tracking, and is treated differently from advertising cookies.
• Keep the cart across the switch. This is the practical argument for the subfolder structure above.

Translation is a content job, not a software feature

The technical work above can be specified and tested. The translation cannot, and it is where bilingual projects actually stall. Hire someone from the community that shops with you — not an agency, not a relative who "speaks Yiddish," not a machine with light editing after. The difference between a business that sounds like itself and one that sounds like a government pamphlet is entirely word choice.

1. Export every string that needs translating into one document — page text, buttons, form labels, error messages, email templates, product names. Do it once, in full. Translating in dribs and drabs is where inconsistency creeps in.
2. Agree a short glossary first: how you write delivery, pickup, order, credit card, in stock. Same word every time.
3. Have a second community member read the finished pages on a phone before launch. Typos in Hebrew letters are invisible to anyone who doesn't read the script, and one wrong letter can produce a real word with an unintended meaning.
4. Decide who maintains it. Every new product, sale banner, and holiday-hours notice now needs two versions. That ongoing cost is larger than the build cost, and it is why so many bilingual sites end up with a stale second language.

A translated page is not always the right page, either. Your Yiddish-reading customers may care about different things — erev Shabbos cutoff times, pickup rather than shipping, a phone number rather than a form.

What it costs, honestly

Building it in from the start is not expensive: a site designed with logical properties and a two-script font handles a second language with modest extra work, mostly the second set of pages and the testing. Retrofitting is a different project — every layout rule revisited, every icon audited, every form and email checked. As a planning rule of thumb rather than a quoted price, assume a second language added to a finished site costs a meaningful fraction of the original build, not a small add-on. Translation is billed separately, usually per word, and Yiddish sits at the higher end of the market range because the pool of qualified translators is small.

For many businesses the honest answer is a narrower scope: keep the main site in English and build a small number of genuinely well-made Yiddish or Hebrew pages that carry the weight. Cheaper, faster, and it stays accurate. Our guide on what a website should cost covers scope generally.

Before you launch: a short test list

1. Open it on a Windows PC and an Android phone, not only the designer's Mac. Font fallback differs by device.
2. Click every arrow, chevron, and carousel, and check that the mobile menu slides in from the correct side.
3. Type a phone number, an email address, and a Hebrew name into checkout and watch the cursor.
4. Place a real test order. Read the email in Gmail, Outlook, and iPhone Mail; print the packing slip; export the order to a spreadsheet and open it.
5. Search your own site the way a customer types — no vowel points, ordinary apostrophes.
6. Have a native reader check it. Not the developer, and not you if you don't read it fluently.

The short version

• Right-to-left mirrors the whole page. Set direction and language on the page itself and build with CSS logical properties so one set of rules works both ways.
• English words, prices, phone numbers, and product codes inside Hebrew render in confusing order unless each is isolated — and the same problem hits emails, receipts, exports, and printed slips.
• Pick a font that actually contains Hebrew letters, or the browser silently substitutes something ugly that differs on every device. Give Hebrew more line spacing; it has no capitals, often no true bold, and no italics.
• Yiddish is its own language with its own community spelling. Machine translation gets the register wrong, and identical-looking characters can be different text underneath, which quietly breaks site search.
• Each language needs its own URL with reciprocal hreflang tags. Browser-side translate widgets give you nothing in search. A switcher must land on the equivalent page, keep the cart, and never auto-redirect.
• Plan it in at the start. Retrofitting right-to-left onto a finished site is a project, not a settings change.

If you are weighing a Yiddish or Hebrew version of your site and want a straight answer about what it would involve, you can start a project, email info@bhwebsolutions.com, or call 845-587-0531. Written questions are welcome and answered in writing.