Server-side PDF rendering (document snapshot + emailed attachment) renders the template in the document's language but nomenclature values in the default language

[NicoleNG18]

Summary

The two server-side PDF render paths — the immutable snapshot copy minted when a document is issued, and the attach: print PDF emailed to the customer — render the print template in the document's language (document.Language) but resolve the data values (Payment Method, Sent Method, Status, and any multilingual nomenclature) in the default language. For any document whose Language is not the default, the stored copy and the emailed PDF come out with, e.g., Bulgarian labels but English values.

This is the same class of defect as the client-side print-language bug, but on a different (server-side) code path, so the client-side fix does not address it. It is also more serious, because it corrupts the legally-archived immutable copy and the customer-facing email, and there is no UI-locale workaround (these run in a BPM service task with no request/user).

Reproduction (verified live)

1. Create a Sales Invoice with Language = Bulgarian, a customer, and a line item.
2. Run the approval workflow to ISSUED (this triggers the snapshot generator).
3. Open the generated copy under Documents → Attachments → SalesInvoiceCopy → … (e.g. SI00000001_..._v1.pdf).

Result: the PDF renders the Bulgarian template (ФАКТУРА, КЛИЕНТ, ПАДЕЖ, ДДС…) but the values read "Bank transfer" / "E-mail" / "ISSUED" (English) instead of "Банков превод" / "Имейл" / "Издадена".

Confirming the mechanism directly against the feeder (which is what the server-side path calls):

• GET …/SalesInvoicePrintFeeder/ with no Accept-Language (the server-side situation) → Bank transfer / E-mail / ISSUED
• same call with Accept-Language: bg → Банков превод / Имейл / Издадена

So the values follow the ambient request locale; with none set (BPM task), they fall back to the default language regardless of document.Language.