3 added 272 characters in body
source | link
2 added 272 characters in body
source | link

Interpreting keyboard shortcuts, function keys (e.g. the left and right arrow don't mean the same if you use a left-to-right language or a right-to-left one) or users commands is in principle a responsibility of the controller (disclaimer: I mean the controller in the sense of the original MVC model;original MVC pattern; some modern variants might defer this to the view as well).

  • Currency: if you have an USD value in your model, it will not be sufficient to display the label EUR, GBP or JPY of the local currency ! Currency valuesCurrency values generally require a proper conversion. But using which rate: the historical rate at the time the amount was registered ? or the rate of the previous day ? or the intraday rate at the exact second of the display refresh ? In advanced accounting packages you may even work with several currencies in parallel: the currency of the group, the currency of the subsidiary for reporting to the local authorities, and the currency of the transaction (which might obey different conversion rules for the group's and the subsidiary's currencies). This is why currency is in principle in the model.
  • Units of measures: measures can be expressed in metrimetric (liters, meters, centimeters, ...) and the imperial system (gallons, yards, inches,...). Fortunately, it's simpler than the currency: there is no daily conversion rate. So you could very well assume one system in your model and convert on the flow into the other at the view level (but you can crash a satellite with the wrong assumptions). For some applications it's sufficient. But if you have business software that will add up many units of measures, the rounded converted sum might not correspond to the sum of the rounded converted items. To avoid such inconsistencies, you may need to address this in the model.
  • Some systems are designed to be multilingual. For exampel a sales system may manage products with a description for each supported language, so that a German customer will see the German description on his invoice and the Japanese client will see the Japanese text. In this case, you need to add language to your model.

Interpreting keyboard shortcuts, function keys (e.g. the left and right arrow don't mean the same if you use a left-to-right language or a right-to-left one) or users commands is in principle a responsibility of the controller (disclaimer: I mean the controller in the sense of the original MVC model; some modern variants might defer this to the view as well).

  • Currency: if you have an USD value in your model, it will not be sufficient to display the label EUR, GBP or JPY of the local currency ! Currency values generally require a proper conversion. But using which rate: the historical rate at the time the amount was registered ? or the rate of the previous day ? or the intraday rate at the exact second of the display refresh ? In advanced accounting packages you may even work with several currencies in parallel: the currency of the group, the currency of the subsidiary for reporting to the local authorities, and the currency of the transaction (which might obey different conversion rules for the group's and the subsidiary's currencies). This is why currency is in principle in the model.
  • Units of measures: measures can be expressed in metri (liters, meters, centimeters, ...) and the imperial system (gallons, yards, inches,...). Fortunately, it's simpler than the currency: there is no daily conversion rate. So you could very well assume one system in your model and convert on the flow into the other at the view level. For some applications it's sufficient. But if you have business software that will add up many units of measures, the rounded converted sum might not correspond to the sum of the rounded converted items. To avoid such inconsistencies, you may need to address this in the model.
  • Some systems are designed to be multilingual. For exampel a sales system may manage products with a description for each supported language, so that a German customer will see the German description on his invoice and the Japanese client will see the Japanese text. In this case, you need to add language to your model.

Interpreting keyboard shortcuts, function keys (e.g. the left and right arrow don't mean the same if you use a left-to-right language or a right-to-left one) or users commands is in principle a responsibility of the controller (disclaimer: I mean the controller in the sense of the original MVC pattern; some modern variants might defer this to the view as well).

  • Currency: if you have an USD value in your model, it will not be sufficient to display the label EUR, GBP or JPY of the local currency ! Currency values generally require a proper conversion. But using which rate: the historical rate at the time the amount was registered ? or the rate of the previous day ? or the intraday rate at the exact second of the display refresh ? In advanced accounting packages you may even work with several currencies in parallel: the currency of the group, the currency of the subsidiary for reporting to the local authorities, and the currency of the transaction (which might obey different conversion rules for the group's and the subsidiary's currencies). This is why currency is in principle in the model.
  • Units of measures: measures can be expressed in metric (liters, meters, centimeters, ...) and the imperial system (gallons, yards, inches,...). Fortunately, it's simpler than the currency: there is no daily conversion rate. So you could very well assume one system in your model and convert on the flow into the other at the view level (but you can crash a satellite with the wrong assumptions). For some applications it's sufficient. But if you have business software that will add up many units of measures, the rounded converted sum might not correspond to the sum of the rounded converted items. To avoid such inconsistencies, you may need to address this in the model.
  • Some systems are designed to be multilingual. For exampel a sales system may manage products with a description for each supported language, so that a German customer will see the German description on his invoice and the Japanese client will see the Japanese text. In this case, you need to add language to your model.
1
source | link

Short answer

Internationalisation and localisation (see definitions of the W3C) is not something monolithic. It encompasses a whole set of features some of them being relevant for the view, some for the controller, and some for the model.


Long answer

Localisation

Localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale).

Typically, it's about formatting numbers, dates and time, and using the language of the user in the screen layout and the menus. All this is typically relevant for the view.

Interpreting keyboard shortcuts, function keys (e.g. the left and right arrow don't mean the same if you use a left-to-right language or a right-to-left one) or users commands is in principle a responsibility of the controller (disclaimer: I mean the controller in the sense of the original MVC model; some modern variants might defer this to the view as well).

From localisation to internationalization

Very soon however, the localisation may be about more touchy aspects. For example:

  • Currency: if you have an USD value in your model, it will not be sufficient to display the label EUR, GBP or JPY of the local currency ! Currency values generally require a proper conversion. But using which rate: the historical rate at the time the amount was registered ? or the rate of the previous day ? or the intraday rate at the exact second of the display refresh ? In advanced accounting packages you may even work with several currencies in parallel: the currency of the group, the currency of the subsidiary for reporting to the local authorities, and the currency of the transaction (which might obey different conversion rules for the group's and the subsidiary's currencies). This is why currency is in principle in the model.
  • Units of measures: measures can be expressed in metri (liters, meters, centimeters, ...) and the imperial system (gallons, yards, inches,...). Fortunately, it's simpler than the currency: there is no daily conversion rate. So you could very well assume one system in your model and convert on the flow into the other at the view level. For some applications it's sufficient. But if you have business software that will add up many units of measures, the rounded converted sum might not correspond to the sum of the rounded converted items. To avoid such inconsistencies, you may need to address this in the model.
  • Some systems are designed to be multilingual. For exampel a sales system may manage products with a description for each supported language, so that a German customer will see the German description on his invoice and the Japanese client will see the Japanese text. In this case, you need to add language to your model.

Internationalisation

Internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.

According to this definition, you can design your application from the start for internationalisation. You then have the choice on where to put it:

  • You can very well let in as implementation detail of the view and use configuration files (linux), embedded string resources (macOS), or additional DLL (windows).
  • But you could chose to make it data/content like any other, with use cases for its management. A great part of the localization would then end-up in the model. It would not be my personal first spontaneous choice, because it could blur the strong lines between view and model and makes your software uterly complex to manage.

Despite my own preference, I won't be dogmatic: in the end it depends on the context, the costs and the expected benefits. If you're for example a major worldwide ERP vendor and you consider this as a critical market differentiation feature, you could very well consider it.