Heh... For a long time I wanted to fix the message Postgres shows when connecting to the Database with the higher version of the CLI as it gives a somewhat misleading perception of lack of backwards compatibility.
Every time I accidentally stumble into that message, I check on the Postgres code, see how hard it is to fix the message and bail out.
If you just make a change of code, you don't need to handle translations at that time. That will get done by the various translation teams closer to the release. However you do need to make sure that the code is translatable (e.g. injecting pre-formulated english messages into a larger message is problematic).
Heh... For a long time I wanted to fix the message Postgres shows when connecting to the Database with the higher version of the CLI as it gives a somewhat misleading perception of lack of backwards compatibility.
Every time I accidentally stumble into that message, I check on the Postgres code, see how hard it is to fix the message and bail out.
That should be trivial to change:
https://github.com/postgres/postgres/blob/d2f24df19b7a42a094...
They would need to handle all the translation changes as well, no?
<https://github.com/search?q=repo%3Apostgres%2Fpostgres+%22ma...>
I agree code change is simple, but I guess the task is complex for other reasons
If you just make a change of code, you don't need to handle translations at that time. That will get done by the various translation teams closer to the release. However you do need to make sure that the code is translatable (e.g. injecting pre-formulated english messages into a larger message is problematic).
Think of all the translations )
You don't need to deal with them as a patch author :)