Support different languages on screen and printer?

I have a restaurant in Thailand serving English speaking customers.
Service staff can use the POS screens in English fine.
Bills and receipts to customers need to be printed in English.
Kitchen orders should be in Thai, or better … 2 or more languages.
(There are a mixture of Thai, Burmese, and Cambodian kitchen staff)
I could get by using existing numeric menu codes, but it would be inefficient, and there would be trouble with dish options which need to be ordered in English and printed in Thai (or better …printed in both Thai and English.)

I also need to know if printer line spacing is configurable because Thai uses accent marks both above and below the normal character height which can produce a crammed rendering in some s/w.

btw. if i use SambaPOS, I will probably be able to provide Thai localization data, or has it been done?

Thank you

This can be achieved with a bit of extra work.
V4 does not support other language localization at the moment, whereas V3 does.
Have a look here for similar solutions to your question

Printer line spacing is not set by SambaPOS, its actually the printer or Windows printer driver that will control this.

Thank you for the info!

I am keenly following the thread you pointed me to which contains a partial solution to a problem printing Thai on the ticket printer.

For printing Thai characters correctly, the printer type needed to be set to “Windows Printer” instead of “Ticket Printer”. But that user here in Thailand still has a remaining issue with the size of the printed characters being larger than normal (when configured as “Ticket Printer”).

see that thread about Thai printing issue

It might help to know that Thai has accent marks which are rendered by overlapping characters, which means that one printed character is sometimes made up of 2 or 3 sequential characters. When the Thai code page is selected, any decoding s/w must be aware of that strange behaviour. Is this affecting “Ticket Printer” mode in SambaPOS? The s/w needs to also take into account that encoded string length is not the same as rendered string length.

This probably relates to other Asian languages as well.
I hope this helps!