Localisation 5 August 2026
Date, Time and Currency Formats: The Silent Layer of Localisation
Full stop or comma, day or month first, symbol before or after? When date, time, number and currency formats are wrong, trust is lost even if the text itself is correct.
Every sentence on a page can be flawless Turkish. The user still hesitates at the price, misreads the delivery date, or gives up at the payment step. The cause is not the translation. When date, time, number and currency formats fail to meet local expectations, trust is lost even though the text is correct.
Contents
The book describes this area as the oldest layer of localisation. In the early years of software localisation, the scope of cultural adaptation consisted largely of these technical adjustments: numbers, names, date and currency formats, measurements, times, sorting orders, keyboard mappings (Jiménez-Crespo 2024, pp. 94-95).
This article takes that layer apart piece by piece. From date and time display to the decimal separator, from currency formats to name ordering, we look at which decisions have to be made and where the information behind them comes from. The layer is silent, but its errors are among the costliest.
What exactly does a locale cover?
A locale is the body of rules that arises from the combination of a language and a region. The book opens this scope up with concrete questions: which units of measurement are used in the target culture? Which calendar applies? When sorting, does the given name or the family name come first? Where is the currency symbol placed (Jiménez-Crespo 2024, pp. 94-95)?
What these questions have in common is that their answers have nothing to do with translation. None of them is a matter of word choice; every one of them is a data display rule. That is why they never appear in the text file the translator is working with, and why most of the time they fall inside nobody’s remit.
This gap in responsibility is the biggest problem in the layer. The software team takes it for translation work, while the translation team counts it as a software setting. In the end nobody decides, and the source country’s format stays in place by default. That silent default is the most frequently repeated flaw in localisation.
The remedy is simple but neglected: gather the format decisions into a single list and write down a responsible team for each line. The list will be short, no more than twenty lines. In return it removes the most insidious class of error in the project and offers a ready starting point whenever a new language is added.
Date and time formats
Date display is the classic trap of localisation. A date written in figures alone produces an ambiguity that doubles the moment the order of day and month is unknown. To one reader 05.03.2026 is the fifth of March; to another it is the third of May.
The price of that ambiguity turns into concrete harm in contracts, flights, appointments and deliveries. The safest solution is to spell the month out in words on dates shown to the user. For data transfer between systems, a standard machine format is needed instead.
A similar split exists on the time side. The choice between twelve-hour and twenty-four-hour display is cultural. Decisions about the time zone, daylight saving and which day the week begins on are added to it. Calendar components usually overlook that last detail.
The calendar system is a decision as well. The book counts the question of which calendar is used in the target locale among those that have to be asked (Jiménez-Crespo 2024, pp. 94-95). Assuming a single calendar in a global application produces wrong holiday calculations and wrong periodic reports in some markets. Holidays tied to a religious calendar fall within this scope too.
Number formats: full stop or comma?
Decimal and thousands separators are the most dangerous of the format errors, because the error escapes the eye; the number still looks like a number. Only its value has changed. A thousandfold deviation has serious consequences in price lists and technical documents.
The problem shows up above all in data copied out of spreadsheets. A decimal written with a full stop in the source file can be read as a thousands separator in the target system. For conversions of this kind, numbers need to be held in a data field rather than inside the text.
The position of the percentage sign, the display of negative numbers and the size of digit groups belong under the same heading. They look like minor details; on a finance screen, though, they determine the impression of reliability outright.
Currency formats: where does the symbol go?
One of the questions the book asks directly is where the currency symbol is placed in different locales (Jiménez-Crespo 2024, p. 95). In some languages the symbol comes before the number, in others after it. Whether or not a space sits between the two also depends on the locale.
Currency formats are not just a matter of symbol placement. How many decimal places are shown, the rounding rule, and whether a code or a symbol is used on multi-currency screens are separate decisions. In an international context, three-letter standard codes reduce the confusion.
Cases where several countries use the same symbol call for extra care. An amount given with the symbol alone leaves the user hesitating once it is unclear whose currency it is. On sites selling internationally, showing the symbol together with the code takes up a little room on screen but removes the misreading altogether.
On the commercial side, the real question is what the displayed price includes. Whether tax is included, whether shipping is shown separately, and which rate the currency conversion uses affect the user’s purchase decision as much as the price itself.
Measurements, paper size and the keyboard
The scope of the technical level takes in keyboard layouts, writing systems, units of measurement and paper formats as well (Jiménez-Crespo 2024, p. 101). Most of these never catch the user’s eye, yet they surface the instant a document is printed or a form is filled in.
Unit conversion matters particularly in product descriptions. A furniture dimension, a temperature value or a distance has to be given in the system used in the target market. Solving the conversion in the data layer is always safer than doing it by hand inside the text.
Paper size, for its part, causes trouble in document production. A template designed for one paper standard breaks its margins and page breaks when it is printed at another size. On invoice and contract templates this setting has to be fixed from the outset. A printed document stays in someone’s hands far longer than the version on screen.
Given name, family name and sort order
One of the questions the book puts is about sorting: when sorting in Chinese, does the given name or the family name come first (Jiménez-Crespo 2024, p. 95)? This question bears directly on form design, address labels, the ordering of lists and search results.
Forms that split the name into two fields are problematic for much of the world. Using a single full-name field is safer in most situations. Where a split is unavoidable, the order in which the fields are shown should be set according to the locale.
Alphabetical sorting is not as simple as it looks either. Every language has its own letter order, and the default code sort breaks that order. If language-sensitive sorting is not used in the lists shown to the user, a user who cannot find the name they are after will assume the list is broken.
Where do you get this information?
None of these decisions should be left to guesswork. The book states that information on the technical level can be found in common locale data repositories, and points to the Unicode Common Locale Data Repository as a source (Jiménez-Crespo 2024, p. 101). This repository compiles format rules language by language.
| Item | Whose decision? | Where is it resolved? |
|---|---|---|
| Date and time display | Software | Locale library |
| Decimal and thousands separator | Software | Number formatting function |
| Currency and tax display | Product and legal | Pricing layer |
| Name fields and sorting | Product | Form and data model |
| Unit conversion | Content | Data field, not text |
The table has only one point to make: most of these problems cannot be solved at the translation stage. If the translator corrects the format by hand, the error comes back in the next release. The lasting solution is to move the formatting into the code.
That distinction affects the budget too. A process that fixes format errors by hand in every release produces a recurring monthly cost. A locale infrastructure set up correctly once, by contrast, adds no extra load when new markets open. This is generally the fastest-returning item in a localisation investment.
The Türkiye context
In the Turkish locale, dates are written in the order day.month.year with a full stop as the separator. In numbers the decimal separator is a comma and the thousands separator a full stop: 1.250,50, for instance. If those two rules are inverted in a price list carried straight over from an English source, the resulting error escapes the eye but the amount turns out to be something else entirely.
A second problem specific to Turkish is case conversion. In the Turkish alphabet the dotted and the dotless i are separate letters. A lower-casing operation that is not locale-sensitive turns a capital I into a dotted i. This leads to silent errors in a great many places, from e-mail addresses to search queries.
The third point is alphabetical sorting. In Turkish the letters ç, ğ, ı, i, ö, ş and ü have a fixed place. When the default sort is used, these letters are thrown to the end of the list. In lists of cities, provinces and people this misleads the user directly, and it is easy to put right. Using a locale-sensitive sorting function is a one-line change in most environments.
What this means for you
When you place a translation order, make it clear who carries responsibility for the format decisions. If these items are not in the brief, the wrong result will be produced without any party being at fault. The cost of getting it wrong is usually paid at the customer service desk.
- List every format that appears on screen: date, time, number, currency, measurement.
- Write the target display for each one with a single example; give an example rather than a description.
- Confirm whether the formatting is done in the code or in the text.
- Test that locale-sensitive functions are used for Turkish case conversion and sorting.
- State clearly whether tax is included in the displayed price.
We explain how these checks are run in document and interface translation on our services page; to scope out your project, get in touch with us.
Frequently asked questions
How is a date written in Turkish?
The common usage is the order day.month.year, with a full stop as the separator. The form that spells the month out in words is correct as well, and it removes the risk of confusion entirely.
Which is the decimal separator in Turkish?
The decimal separator is the comma and the thousands separator is the full stop. Numbers carried straight over from a source text can therefore lead to thousandfold errors.
Where does local format information come from?
Common locale data repositories are used. Unicode CLDR is the most widespread of them and compiles date, number, currency and sorting rules language by language.
Who should fix format errors?
These errors are mostly resolved on the software side. If the translator corrects the format by hand one instance at a time, the error returns in new releases; the lasting solution is a locale library.
References
- Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 94-101.
- Unicode Consortium. Common Locale Data Repository (CLDR), UTS #35. unicode.org.
- Türk Dil Kurumu. Yazım Kılavuzu, sections on punctuation and the writing of numbers.