Localization

The Mobiscroll Connect pages — where the user selects a calendar provider, signs in, and approves the consent screen — are localized. You choose the language by passing the lng parameter when you start the authorization flow, so the pages render in the same language as the application that sent the user there.

Localization applies to the user-facing Connect pages only. API JSON responses and webhook payloads always remain in English.

Supported languages

Code	Language	Direction
en	English	Left-to-right
es	Spanish	Left-to-right
fr	French	Left-to-right
de	German	Left-to-right
it	Italian	Left-to-right
pt-PT	Portuguese (European)	Left-to-right
pt-BR	Portuguese (Brazilian)	Left-to-right
ar	Arabic	Right-to-left

Region-qualified codes

lng accepts region-qualified codes in the xx-YY form. European and Brazilian Portuguese are separate languages here, not one shared Portuguese — they differ in vocabulary, grammar and how the progressive is formed, so pick the one that matches your users.

Codes are written with a hyphen, as in pt-BR. Matching is case-insensitive, and an underscore is accepted in place of the hyphen, so pt-BR, pt-br, PT-BR and pt_BR all select Brazilian Portuguese.

When a code does not match a language in the table exactly, Connect falls back in this order:

1. A region variant we ship — ?lng=pt-BR uses Brazilian Portuguese.
2. The bare language, if we ship it — ?lng=de-CH and ?lng=es-MX use German and Spanish.
3. The language's default variant — a bare ?lng=pt, or a Portuguese region we do not ship separately such as pt-AO, uses European Portuguese.
4. English.

Setting the language

The language is selected with the lng query parameter on the authorize URL — the same URL that opens the Connect pages. This is the recommended way for a calling application to pass a locale.

When you use one of the SDKs, pass lng to the auth-URL builder instead of constructing the query string by hand.

REST

GET /authorize?client_id=proj-123&user_id=user-456&response_type=code&lng=es

Node.js SDK

const authUrl = client.auth.generateAuthUrl({ userId: 'user-456', lng: 'es' });

Python SDK

auth_url = client.auth.generate_auth_url(user_id='user-456', lng='es')

PHP SDK

$authUrl = $client->auth()->generateAuthUrl(userId: 'user-456', lng: 'es');

.NET SDK

var authUrl = client.Auth.GenerateAuthUrl(new AuthorizeParams { UserId = "user-456", Lng = "es" });

Java SDK

String authUrl = client.auth().generateAuthUrl(
    AuthUrlParams.builder().userId("user-456").lng("es").build());

Go SDK

authURL := client.Auth().GenerateAuthURL(&mobiscroll.AuthURLParams{UserID: "user-456", Lng: "es"})

Ruby SDK

auth_url = client.auth.generate_auth_url(user_id: 'user-456', lng: 'es')

See the lng request parameter on the Authorize endpoint for the full API reference, and your SDK's integration guide for the exact syntax.

Language fallback

If lng is not provided, Connect resolves the language in the following order:

1. The lng query parameter, when present.
2. The user's browser Accept-Language header.
3. English (en) as the final default.

Accept-Language is matched the same way as lng, so a browser sending pt-BR,pt;q=0.9 gets Brazilian Portuguese and one sending pt-PT gets European Portuguese. See Region-qualified codes for the order Connect tries.

Existing integrations that do not pass lng continue to work without changes — users whose browser language is supported now see the Connect pages in that language automatically. To force English regardless of the browser, pass lng=en explicitly.

Right-to-left (RTL)

Arabic (ar) is the first right-to-left locale. When ar is active, the Connect UI direction switches to right-to-left automatically — no extra configuration is required.

What gets localized

The localized pages are the provider selection (authorize), the iCloud and CalDAV login pages, and the error page. Anything your application consumes programmatically — API responses and webhook notifications — stays in English regardless of lng.

Related

• Authorize API reference — the lng parameter and the full authorization request.
• Scopes & Permissions — the other core concept that shapes the authorization request.