2014-02-12 03:13:56 +04:00
|
|
|
x-test:
|
|
|
|
requested_object_not_found: "##x-test## requested object not found"
|
|
|
|
user_id_is_required: "##x-test## User id is required"
|
|
|
|
source_type_must_be_user_thread_or_other: "##x-test## Source type must be 'user', 'thread' or 'other'"
|
|
|
|
value_is_required: "##x-test## Value is required"
|
|
|
|
value_is_invalid: "##x-test## Value is invalid"
|
|
|
|
anonymous: "##x-test## anonymous"
|
|
|
|
blocked_content_with_body_hash: "##x-test## blocked content with body hash %{hash}"
|
|
|
|
param_must_be_a_non_negative_number: "##x-test## %{param} must be a non-negative number"
|
|
|
|
param_must_be_a_number_greater_than_zero: "##x-test## %{param} must be a number greater than zero"
|
Add a default response size and a response size limit.
By default, we currently allow a user to retrieve all responses from a
thread, which is terrible from a performance standpoint.
This change adds a default response size of 100, which was chosen to
match typical production pagination parameters, and a response limit of
200. Given that responses can include children comments, 200 is still a
large number, but far less disastrous than, say, getting 3000 responses,
with all of their children comments.
Both of these values are configurable, and can be overriden via
environment variables.
2016-11-01 16:59:36 +03:00
|
|
|
param_exceeds_limit: "##x-test## %{param} exceeds limit: %{limit}"
|
|
|
|
cannot_specify_group_id_and_group_ids: "##x-test## Cannot specify both group_id and group_ids as filters."
|