Closed jspetrak closed 4 months ago
CIT defines train ticket language rules - in general "should be in language of the passenger".
CIT MIRT: 6.5.3 Languages The type of ticket is to be given in the language(s) of the country of issue. If that should not happen to be English, French, German or Italian, then the information is also given in one of those languages. 21) All other details are only to be given in the language(s) of the issuing country except where the tickets are issued overseas (Africa, Asia, Australia and Oceania, North and South America) when all the other information is to be given in English. Where there is insufficient space for a second language on tickets which are small in size, such as the RCCST (see point 7.9, Plate B), the three-character acronym in accordance with Chapter 3 of UIC leaflet 918-2 will suffice as the description of the type of ticket. The CIT provides members with a translation of the most important terms used on international tickets in the main CIT and UIC languages (see Appendix 1).
For interface we want to use the accept-header For communication, we use one of the preferred-languages, depending on the communication type (confirmation, real time info etc) For fulfillment, we need to discuss further
This will be placed in the documentation
I would note that Content-Language
header that was mentioned today is an interesting option for setting the language af the FulfillmentDocument
. However, the documentation states it is used to describe intended language audience of the document and not the actual langague of the document. It possible restricted to HTTP responses only.
Related to languages on tickets and communication to customer/retariles I´d follow CIT MIR directive as Joseph and Clemens mentioned. And as we´re currently doing. For the rest, mostly the interface itself, English seems to me the best option. In my humble opinion.
Accept language only where it is relevant In addition we need to be consistent for the reference data and use the same : We probably should have a main label + translations
So, to sum up the concrete impact on specifications:
General elements:
For interface language, we will rely on the accept-language, but only keep it in calls where can be relevant.
For communication language (emails etc), we refer to the purchaser preferred language, or the passenger language if possible and applicable
For fulfillment language,
What the documentation currently states
What is defined in the swagger
Languages as they apply in the business (benerail view)
Usually in our business, we can distinguish the following use cases where language or localised information is relevant:
So, what is wrong ?
Benerail proposal