Bulgarian localisation guide

Cyrillic text and Bulgarian letterforms

Bulgarian uses Cyrillic. Fonts can contain language-specific letterforms that differ from the default Cyrillic shapes, particularly in lowercase letters such as д, т, в and и. These are glyph differences, not a different spelling system. A text should retain its correct Unicode characters while the font and shaping system select the intended Bulgarian forms.

The OpenType locl feature supports localised glyph substitution. Correct Bulgarian language tagging and a font containing the required substitutions are both important. A stylesheet cannot create missing glyphs. Some fonts use Bulgarian forms by default, so the exact file and its behaviour need checking rather than assuming that a family name guarantees a particular result. Source: Microsoft OpenType feature documentation.

Representative tests should include lowercase text, capitals, italics, bold, numerals and punctuation. Browser fallback can introduce a second typeface when a character is absent. The Bulgarian translation page describes the language service; implementation teams remain responsible for checking the exact fonts and rendering used in their product.

Transliteration is a separate operation

Transliteration writes Cyrillic text in Latin letters; it does not translate meaning. Bulgaria’s Transliteration Act was promulgated in 2009 and codifies the Streamlined System. Its scope includes specified geographical names, historical figures, cultural terms and Bulgarian-origin scientific terms, with provisions for official use and other defined contexts. It is not a blanket instruction to replace Bulgarian-language content with Latin text. Source: MRDPW, Transliteration Act. Checked 31 October 2026.

The Act’s table includes ж → zh, ч → ch, ш → sh, щ → sht, ъ → a, ю → yu and я → ya. Special rules apply, including word-final ия → ia and the established spelling Bulgaria. These examples are insufficient for a complete converter: the applicable rules and exceptions must be considered together. Source: Transliteration Act, Articles 4–6. Checked 31 October 2026.

A product brief should distinguish an approved Latin brand spelling from transliteration of a place name. A person’s recorded Latin spelling should not be regenerated casually from Cyrillic. Search aliases may support several forms without changing the authoritative display value. An automatic transliteration routine is therefore a data feature needing defined scope, rather than a substitute for editorial decisions.

Dates, times and numbers

Bulgarian display dates commonly follow day–month–year order, with dotted numeric forms such as 31.10.2026. A long form can read 31 октомври 2026 г. A 24-hour time such as 14:30 is suitable for many business interfaces. The locale-aware formatter should determine the exact presentation, while the underlying date and time data retain a defined time zone and machine-readable structure.

Numbers use a decimal comma, and grouped thousands commonly use a space: 1 234,56. A non-breaking space can keep a group or currency amount together. Applications should use a locale formatter rather than replacing commas and full stops in a string. A source value such as 1,234 can otherwise be interpreted as a decimal or a grouped integer depending on its origin.

Date entry and display need separate decisions. An application can display a Bulgarian date while exchanging ISO-formatted dates with another system. Input validation should explain the accepted format and handle the actual date, not merely the order of digits. Ambiguous examples, placeholder text and imported spreadsheets need to be checked alongside the visible form label. Source for locale patterns: Unicode CLDR Bulgarian data.

Euro adoption: current amounts and historical BGN

Bulgaria adopted the euro on 1 January 2026. The European Central Bank confirms that euro banknotes and coins entered circulation that day and records the fixed conversion rate of 1 euro = 1.95583 Bulgarian lev. The euro is therefore the current currency for Bulgarian market planning as of this article’s date. Source: ECB, ‘Bulgaria introduces the euro’. Checked 31 October 2026.

BGN remains relevant when describing historical lev amounts and records. A system should retain the currency code alongside each value. Relabelling an old BGN amount as EUR changes its meaning without performing a conversion. A migration plan should distinguish stored transaction data, current price displays, exported reports and archived documents, with financial rules approved by the responsible business owner.

Locale formatting and currency conversion are separate tasks. Selecting Bulgarian as the display language does not determine whether a record is denominated in euros or lev. Any requirements for dual display, rounding or document conversion should be checked against the applicable official rules for the relevant date and transaction. This guide does not establish those transaction-specific obligations.

Quotation marks, register and formal address

Bulgarian normally uses low opening and high closing quotation marks: „текст“. Straight quotes may be necessary in code, but should not automatically replace typographic quotation marks in editorial copy. Product names, quoted interface labels and nested quotations need consistent treatment in the style guide. Punctuation should be checked in the final font as well as in a text editor.

Formal Bulgarian address uses plural verb forms. The polite pronouns Вие and Ви take an initial capital when used as the courteous form; ordinary plural reference is different. A brand should decide its register and keep it consistent across messages, help text and correspondence. Source: Institute for Bulgarian Language, language advice on polite pronouns.

Literal English wording often produces awkward Bulgarian commands and noun strings. A button label needs to fit the action, while a status message describes a state. Fragmented sentences assembled from separate strings can create agreement problems. Full messages, context notes and screenshots let the linguist choose grammar that remains correct when a variable changes.

Expansion, grammar and constrained layouts

Bulgarian text can be longer than its English source, especially in short interface labels. No fixed expansion percentage works for every screen. The implementation should allow flexible widths, wrapping and sensible minimum heights. Character limits need a reason and a counting method: a database limit, display width and maximum number of lines are different constraints.

Plural and agreement handling should use the platform’s locale facilities. A label concatenated with a quantity may need a different form from the same word used in a heading. Context should identify the placeholder’s possible values and grammatical role. A linguist can then assess the whole message instead of trying to translate an isolated word with several incompatible uses.

In website translation, navigation, metadata and form feedback need the same attention as body copy. In software localisation, error messages and empty states also require testing. A screenshot review should use realistic long content and representative data, including amounts and dates, rather than only the shortest successful screen.

Sorting, keyboard layouts and search

Bulgarian alphabetical ordering should use locale-aware collation rather than raw character-code order. Mixed lists containing Latin product names, Cyrillic names and numbers need an explicit policy. The display order and the search-matching policy can be different. For example, an internal code may remain exact while a human-readable name supports case-insensitive matching.

Bulgarian users may enter text through a standard Bulgarian keyboard layout or a phonetic layout. Microsoft documents Bulgarian and phonetic variants as distinct layouts. A product should accept valid Cyrillic input regardless of how the letters were entered. Tests should include pasted text, keyboard switching and shortcuts that may behave differently across layouts. Source: Microsoft keyboard documentation.

Visually similar Latin and Cyrillic characters are different code points. Mixed-script identifiers can create failed searches or duplicate-looking entries. Validation should follow the field’s purpose: unrestricted personal names and tightly controlled product identifiers need different rules. Automatically converting every Latin-looking character risks altering legitimate data and should not be used as a universal fix.

Hyphenation and final release checks

Hyphenation should follow Bulgarian word-breaking rules. A browser’s automatic hyphenation depends on correct language tagging and available language support. Hard-coded hyphens inserted to make one narrow screen fit can break words on a wider screen or pollute copied text. Where automatic hyphenation is unavailable, flexible layout is preferable to arbitrary splits.

Common release defects include Russian-default glyphs in an otherwise Bulgarian design, Latin letters inside Cyrillic words, inconsistent polite address, English date order, decimal-point assumptions and clipped labels. The project preparation guide explains how context and a review owner prevent many of these issues before final testing. Terminology and typography findings should be recorded separately so each reaches the right owner.