Consider a BS which is deployed in an international company operating globally.
User Story: Customer Orders are entered in Spain, checked in France, fulfilled in Germany, and delivered by the Dutch logistics department.
The following BO exist.
Code: Select all
Product
- Product Name
- Product Size
- Product Stock Balance
OrderHeader
- Order Number
- Customer Number
OrderDetail
- OrderHeader
- Product
- At order entry: Spanish user selects from a list of products in Spanish.
At order check: French user reads the order details and sees the product names in French. Not only that, s/he changes one order line to a different product because the ordered product was superseded by a new product. S/he chooses the new product from a list of products in French.
At order fulfilment: German user reads the German names of products to be picked.
At order delivery: Dutch truck driver checks the Dutch delivery note against the items to be delivered.
- A. A locale attribute in the Product BO.
B. ProductNameLocale BO containing an instance for each Product/Locale combination.
C. Product.Name column each for the supported locales. Eg NameSpanish, NameGerman, NameFrench, NameDutch etc.
Solution B could work the same way as solution A if one can use a presentation of some kind to show the product.productnamelocale.name somehow. (something like a shortcut that can contain a query matching the user.locale with the instance). The rest of the user story fails however.
Solution C does not work firstly because one cannot return a particular column(attribute) based on a WHERE clause in a query.
Has anyone else had to deal with this problem?
It seems to me that a great feature would be to have a new attribute type: LocaleArray which would allow entering the values for each locale and which will present the appropriate value depending on the user locale.
