add "language" connection parameter and translate errors on the server [CORE2295]

[firebird-automations]

Submitted by: Cosmin Apreutesei (cosmin_ap2)

Instead of keeping firebird.msg on the clients in sync with the one on the server all the time (it's a deployment problem) , wouldn't it be better to add "language" as a connection parameter, keep all firebird_XX.msg variants on the server, and make the server return the errors properly translated? Sorry if this has been discussed already, I couldn't find it on the tracker. Thanx.

[firebird-automations]

Commented by: @helebor

...not found in the Tracker because it's already supported? It's pretty much exactly as you think it should be.

See the parameter item isc_dpb_lc_messages (for path to specified message file) in the DPB structure, not to be confused with isc_dpb_lc_ctype (for connection charset).

It is indeed a deployment task to ensure that viable message files are present in the designated paths, of course. Usually it will be a development task as well, since these alt-language message files don't create themselves. ;-)

[firebird-automations]

Commented by: Cosmin Apreutesei (cosmin_ap2)

Thanx. Got bitten by http://www.firebirdfaq.org/faq288/ and now this is another useless post :) Sorry.

Edit:

Ok, now after I've read the API guide which is the only vague source of info for this param, I've found out it's not working (i.e. fbclient.dll still looks for firebird.msg into its _parent_ dir -- dunno why it does that instead of looking in its own dir, but anyway).

Then I found out this old post http://www.nabble.com/messages-file,-intl-version-td4743830.html...

So is this actually supported? If so, any hint of where could I find a list of all currently supported (i.e. for v2.1 and v2.5) dpb params? Thanx again and sorry for continuing this conversation on the tracker.

[firebird-automations]

Commented by: @dyemanov

I suspect this was never supported. Architecturally, the server sends only binary error codes and arguments (aka status vector) to the client. This is reflected in the API and network protocol. This is why the client has to decode the status vector using the message file. While the server has full access to the messages and could decode error codes itself, there's currently no way to deliver the resulting strings to the client side. So, implementation of this ticket would mean some major changes inside the client-server interaction.