87

Most programming languages and frameworks already have a sensible, working mechanism that you can use for this. For example, the C# ecosystem has the System.Globalization namespace, which allows you to specify the Culture you want: Console.WriteLine(myMoneyValue.ToString("C", "en-US")); This is not something that you want to re-invent. Use the ...


35

Is there a use-case for build-in currency formatting? Basically, with currencies you have two ways of working: in a currency-aware environment, where people register amount sometimes in local and sometimes in foreign currency: you will never use the default built-in feature. Instead you’ll store a currency amount and a currency code. in a currency-neutral ...


24

Your REST API will be easier to use by others if you provide string IDs instead of translated strings. Using an API which returns "E_NOT_AUTHORIZED" is more straightforward than if it returns some human-language, and even localized string. Also, you might want to change the localized strings in future versions, which would be a breaking API change. With the ...


23

Some excellent answers here already, but they did not mention one thing which I think is important not to forget: make sure wherever a number formatting takes place, it is clear (or can be controlled) what the output is used for: when it is for the user interface, the localized formatting must be applied when the number is going to be written to a file, or ...


18

I believe that logs and exceptions are for developers, therefore they should be in the best language to suit the development team. This may be their native language, however it may be (and judging from the comments often is) English. This allows developers to work in a language they are familiar with and not have to translate from French, Spanish, or Chinese ...


17

Rather than replacing without understanding I'd like to explain why there appear to be two forms one underscored and another hyphened and why one should care. tl;dr it is not simple as a single char replacement. 1. specifications There is several specification at play here : ICU: The International Components for Unicode which has a section on how to encode ...


16

Too much effort for too little added value. The amount of English required to make sense of the keywords of any programming language is really very small - for the majority of second-language speakers it is probably way less than they already knew of the language even before they became programmers. Conversely, allowing all keywords to be replaced by their ...


14

The main reason is that all source code should be written in English. This applies as well to variable names, comments, etc. The reason becomes obvious when you see for the first time a piece of code which is written in a language you don't know. For example: // Записать изменения конфигурации. var имя = this.RefreshMeta().ПолныйПуть; this.Хостинг.Записать(...


13

You are absolutely right, formatting using a system-dependent currency symbol is dangerous. I actually knew people who lost lots of money through that. Especially with US dollar and Euro being close enough that the numbers make sense. On iOS you typically use a currency code, and the currency code is displayed in a system dependent way. For example, if the ...


12

First off, gettext is a good way to go, so don't dismiss if it doesn't sound easy at first; However there are other options as well that be useful to know. Before explaining that let's take a look at your suggestions first: In your array-way of doing this, you have a pretty much straightforward solution. The good thing is that you can store your ...


12

Definitely the complete text. Different languages use different punctuations, for example, english "Where?" Would be "¿Dónde?" In spanish (note the inverted question mark in the beginning). Different languages will need punctuation (or variable pieces) in different places of the string It's a lot more coding effort to concatenate the pieces together The ...


11

So if i understand you right, you have a non-localised application, which has text in English, but numbers, dates etc are automatically formatted to the CurrentCulture of the machine on which the program runs. Leading to mixed culture strings. Obviously the best thing to do is full localise your application with resx files etc. But I assume this would be ...


11

If you want internationalization that isn't infuriating/weird/offensive/confusing to users, you do one of two things: you take the entire block out and have the copy translated in one go per item, or you remove the narrative sentence structure you propose that includes variable attributes so that you completely avoid differences in language structure. The ...


11

The question seem to be "why programming languages, frameworks and operating systems support features that are not the best practices for professional developers in large multinational corporations"... and the answer is there are sometimes developers who are not in that category. If your language only supports enterprise-level features you will not ...


10

In layman's words: They do. In this wikipedia article you can see there are lots of programming languages/compilers/interpreters based in languages other than english. Here is a sample source code in Linnotte, a French-based programming language: nombre Fibonacci : a est un nombre début questionne a sur "Entrez un nombre :" affiche fibo(a) ...


9

I would accept duplication whenever you cannot be absolutely sure the meaning is exactly the same in all cases a certain string is used. Even if two labels always contain the same string in English (or your native tongue) they will not necessarily be the same in all languages. Accepting duplication may give you (or rather the translators) the flexibility ...


8

Proper localization is quite difficult. Most programming ecosystems have attempts at a solutions for localization, but in my experience they are all more or less broken. I would therefore suggest: Don't try to automate localization. It won't always work. It is difficult for you to spot the problems, and frustrating for your users. Be consistent: don't mix ...


8

There are a lot of long answers to a simple question here. You ask for a use-case and there's a simple one that I don't think has been mentioned yet: games. If a game involving money is set in an ambiguous location, why not use the players local currency? It creates a more immersive experience and, as the feature is built into the language, costs very little ...


7

Thirty years ago or more it was probably still reasonable to assume that most computer systems that dealt with financial amounts, did so exclusively in the local currency. In the English-speaking world and the advanced economies more generally whom computers were built to serve, the local currencies had never changed during the computer era, and many could ...


6

Have clients send the standardized Accept-Language header in requests, then localize on the server and include a Content-Language header in responses. See RFC 7231 Section 5.3.5 for details. Localizing on the server side results in fewer round trips and bandwidth consumption than sending clients localization metadata. But a server can't assume what language ...


6

Localization and internationalization facilities exist for applications, often as library functions (e.g. Posix gettext). In the 1960s and 1970s several programming languages appeared in France with French keywords, e.g. PAF and LSE. However, it makes much less sense to localize the source code of programs and scripts (e.g. by changing keywords of ...


6

By my opinion the exception message should not be translated. if developer can reproduce the exceptional situation at their development environment, the message is not needed at all, they could just attach a debugger and set it up to break at throwing the exception. Exception messages mostly make sense for non-reproducible failures which happen only at ...


6

Is the localization part of your core business logic, or just part of the UI? Message contents, time zones, number formats: those are probably part of your UI. They should be applied as late as possible, i.e. in the app and not already in the API. Your API should likely deliver these values in a normalized format, e.g. UTC for timestamps. Currency ...


6

Basic principles The sentence structure and grammatical subtleties can indeed make the internationalization exercise difficult. The core practices that you'll need to use in all the cases are: separate the text data from the code. Put it in a separate resource file, that you can give to translators. for numeric values, have some code that chan make unit ...


5

Put simply this, like many process questions, comes down to a cost-benefit decision. Quite a few of the practices described in the agile processes are about reducing the time spent in the "last mile" - this is an example of one of them. Unlike practices with other aims (quality, correctness, etc), the practices aimed at ensuring you can release the product ...


5

Apply the "potentially shippable" rule as far as it makes sense. Use your common sense where it doesn't. (Common sense is sometimes called "rule 0" in agile) A team should avoid to commit work that is beyond their own power. Translations typically rely on translators outside the team. So the team shouldn't commit to that. In short: put in your definition ...


5

On the technical side: Querrying the backend using the longitude and latitude (option 2) has the advantage of providing the country in the same way for every platform. However it has the following drawbacks: a user can refuse to share geolocalisation in order to protect his privacy. You won't get lattitude and longitude. THis will break your design. ...


5

TL;DR Currency formatting has been an OS-level configuration for decades now, and the pre-internet days were a very different beast in terms of the frequency of international transactions and the need for someone in region A to express money using region B's currency. I suspect the OS-centric currency settings are a relic of the past, kept in either because ...


4

Replace every occurence of "_" by "-" in the locale string when you receive the parameter and let the logic expect only "-".


4

My question is: what other languages, if any, implement a similar paradigm for programming language internationalization? Fortunately, as far as I know, there are none. I fervently hope it stays that way. Localisation of anything important in a language or an API or any of the various defined symbols and strings that programs depend on, every time I've run ...


Only top voted, non community-wiki answers of a minimum length are eligible