Non-English error message?

[HarelM]

I'm getting the following error message when updating a description using the API with the following error message:
description:he: v: est trop long (pas plus de 255 caractères)
I'm guessing this means that the field can't be more than 255 characters long.
Would be better if it was in English.
Would be super if I could add a description to a point that has more than 255 characters...

[simonpoole]

The background wrt 255 character limit is outlined a bit here #1593 Outside of that, what were you actually using when you got the message? It doesn't seem to be a string on the website/API nor in iD.

[HarelM]

OSM API from my server side.

[tomhughes]

As @simonpoole says that message does not appear anywhere in our code.

[HarelM]

Please reopen. It certainly isn't from my code as I'm not speaking German.
It might be related to the database you are using or the language of the operation system of your servers.
In any case it was returned from your end.
Take the time and find it or leave this issue open.

[zerebubuth]

The message is coming from Rails' translations, which means that the locale is being set to French. This should be set by the client request or user account settings. Is it possible that your user account's default language is set to French, or your browser / HTTP library / web proxy is adding an Accept-Language header for French?

The good news is that you can work around this by adding a [?&]locale=en GET parameter to force the locale to English, which should override wherever the setting to French is coming from. (Please don't do this, it's intended for debugging only and isn't a stable interface. See comments below.)

Our servers all run with LANGUAGE set to en_GB:en, and Rails (in classic anglocentrism) defaults to English (i.e: en_US). Therefore, it seems unlikely to me that we're setting the language to French on our servers. If you think that this is a bug on our side, please provide a full request/response pair so that we can reproduce the error you are seeing, such as the output from curl -v. But please redact the Authorisation header to avoid leaking any of your credentials!

[tomhughes]

Please don't encourage people to use the locale parameter in the URL as that is a debug aid for site developers and might go away at any time,

[zerebubuth]

Ooops, sorry. In that case, it would be best to have a complete (except Authorisation) request and response trace so that we can reproduce this.

[tomhughes]

If he's logged in then it should be entirely down to the preferred language in his user profile and if not then to the Accept-Language header his browser sends.

If there is a bug then it's probably that set_locale isn't being called for some reason in which case you tend to get the language of the last user to hit that server. If the response is consistently french then that is unlikely. In any case we would need to know exactly what API endpoint he is hitting.

[zerebubuth]

I think the only API methods which allow updating something guarded with a length validation require a logged-in user. Once we have a request and response trace we'll have somewhere to start looking.

[HarelM]

I'll send the entire info once I get home. The call is made from a c# http client.

[HarelM]

PUT http://www.openstreetmap.org/api/0.6/node/2819192759 HTTP/1.1
Connection: Keep-Alive
Content-Type: text/plain; charset=utf-8
Accept-Encoding: gzip, deflate
Authorization: OAuth ...
Content-Length: 1897
Host: www.openstreetmap.org

<osm><node id="2819192759" lat="31.8362464904785" lon="35.0608596801758" user="zstadler" uid="3127" visible="true" version="1" changeset="54684429" timestamp="2014-04-26T20:25:22Z"><tag k="ele" v="357.0" /><tag k="name" v="עין נטף" /><tag k="name:en" v="Ein Nattaf" /><tag k="name:he" v="עין נטף" /><tag k="natural" v="spring" /><tag k="source" v="GPS" /><tag k="description:he" v="המצפור מעניק מבט על הנוף המרהיב שמסביב. מכאן ניתן להבחין היטב במורדות המערביים של הרי ירושלים והרי בית אל, הבנויים ברובם גיר קשה, כשהם צונחים מערבה אל גבעות השפלה הבנויות סלעי קירטון רכים. קו המגע בין שתי יחידות הנוף יוצר קו חולשה, המכונה בשפת הגיאוגרפים \&quot;עמק תלם\&quot;. עמק איילון נוצר כתוצאה מהתלכדות עמקי התלם של הנחלים הרבים הפורצים לכאן מהרי יהודה והרי בית אל.\nהעי הגדולה שמצפון היא מודיעין והיישו" /><tag k="description" v="המצפור מעניק מבט על הנוף המרהיב שמסביב. מכאן ניתן להבחין היטב במורדות המערביים של הרי ירושלים והרי בית אל, הבנויים ברובם גיר קשה, כשהם צונחים מערבה אל גבעות השפלה הבנויות סלעי קירטון רכים. קו המגע בין שתי יחידות הנוף יוצר קו חולשה, המכונה בשפת הגיאוגרפים \&quot;עמק תלם\&quot;. עמק איילון נוצר כתוצאה מהתלכדות עמקי התלם של הנחלים הרבים הפורצים לכאן מהרי יהודה והרי בית אל.\nהעי הגדולה שמצפון היא מודיעין והיישו" /></node></osm>

I got a different error response just now:

NodeTag 2819192759,description:he: v: 过长（最长为 255 个字符） ("המצפור מעניק מבט על הנוף המרהיב שמסביב. מכאן ניתן להבחין היטב במורדות המערביים של הרי ירושלים והרי בית אל, הבנויים ברובם גיר קשה, כשהם צונחים מערבה אל גבעות השפלה הבנויות סלעי קירטון רכים. קו המגע בין שתי יחידות הנוף יוצר קו חולשה, המכונה בשפת הגיאוגרפים \\\"עמק תלם\\\". עמק איילון נוצר כתוצאה מהתלכדות עמקי התלם של הנחלים הרבים הפורצים לכאן מהרי יהודה והרי בית אל.\\nהעי הגדולה שמצפון היא מודיעין והיישו")

Seems like the error message is changing according to the text I set inside the description? Not sure, in any case when I sent just numbers I got an English error message.

[tomhughes]

Right. Old style single object changes like that are quite unusual now.

It looks like most api methods never bother calling set_locale so as I said you will get whatever locale the server happens to have used for the last call which did.

Mostly it doesn't matter because our own API errors are all in english I think and don't go through the translations but the errors that come from rails itself are getting translated.

[HarelM]

I'm not sure what you mean by old style. Is there a newer way of updating OSM elements from non-OSM server side code (meaning my server)?
Is there something I should be doing differently in my code?

[tomhughes]

Well most things use changeset diff upload these days rather than the single object change.

It probably doesn't make any difference to this issue anyway as I don't think either of them initialises the locale.

[mmd-osm]

Mostly it doesn't matter because our own API errors are all in english I think and don't go through the translations but the errors that come from rails itself are getting translated.

I wonder if we just can't provide our own :too_long message in English instead? Will that work, i.e. not automatically getting translated by i18n anymore?

node_tag.rb:

  validates :node, :presence => true, :associated => true
  validates :k, :v, :allow_blank => true, :length => { :maximum => 255, 
                       :too_long => "is too long (maximum is %{count} characters)" }
  validates :k, :uniqueness => { :scope => :node_id }

[tomhughes]

That would be a very silly solution.

[mmd-osm]

Yes, I thought so.

Since we want API calls to return messages in English only, could we add something like set_locale_api to the application controller, and set I18n.locale to en_GB:en or en_US. Next would be adding a call to set_locale_api to node_controller.rb in def update, as an example for the one API call in this issue.

I've noticed that before_action :set_locale is used in several places, like notes_controller.rb, but I'm suspecting that may not be a good option for node_controller.rb et. al, as we're again making messages dependent on the user's language settings even for API calls.

[tomhughes]

I don't especially want them to return english only. That was just a comment that we have never made any effort to I18n them.

[mmd-osm]

Side note: I was a bit worried about i18n for api messages, as people might rely in funny ways on them already and it's quite late to introduce them.

As an example, this snippet from Potlatch2 parses the original English error messages and extracts values: https://github.com/openstreetmap/potlatch2/blob/master/net/systemeD/halcyon/connection/XMLConnection.as#L330-L365 - any change to those API messages would immediately break error handling in Potlatch2.