secondary language tags included in lang parameter values are not supported
the language, which is specified in a previous API request, is not used in the SEP-24 interactive flow
Secondary Tag Support
Polaris validates the lang parameter values sent in requests by matching them against the anchor's LANGUAGES settings object. However, this strict matching causes Polaris to reject requests when a secondary language tag is included in the lang value.
For example, if a user wants to read Brazilian Portuguese and specifies pt-br as the lang value in a request to initiate a transaction, Polaris will reject the request with a 400 if settings.LANGUAGES only contains an entry for pt.
This would not occur if the client specified their desired language using the Accept-Language header, which is a case handled by Django directly.
Polaris should use the same validation logic as Django.
SEP-24 Interactive Flow
Additionally, the SEP-24 specification states that the value passed in a POST /transactions/deposit/interactive request should be used for the interactive flow, but Polaris does not currently propagate this information to its interactive flow.
When a client specifies the lang parameter via this request, Polaris should add a query parameter to the interactive URL returned in the response containing the same value passed via lang. When the URL is used to open the interactive flow, Polaris will set the content of the interactive flow to use the specified language for the entire user web session.
This PR addresses 2 bugs in Polaris:
lang
parameter values are not supportedSecondary Tag Support
Polaris validates the
lang
parameter values sent in requests by matching them against the anchor'sLANGUAGES
settings object. However, this strict matching causes Polaris to reject requests when a secondary language tag is included in thelang
value.For example, if a user wants to read Brazilian Portuguese and specifies
pt-br
as thelang
value in a request to initiate a transaction, Polaris will reject the request with a 400 ifsettings.LANGUAGES
only contains an entry forpt
.This would not occur if the client specified their desired language using the
Accept-Language
header, which is a case handled by Django directly.Polaris should use the same validation logic as Django.
SEP-24 Interactive Flow
Additionally, the SEP-24 specification states that the value passed in a
POST /transactions/deposit/interactive
request should be used for the interactive flow, but Polaris does not currently propagate this information to its interactive flow.When a client specifies the
lang
parameter via this request, Polaris should add a query parameter to the interactive URL returned in the response containing the same value passed vialang
. When the URL is used to open the interactive flow, Polaris will set the content of the interactive flow to use the specified language for the entire user web session.