Adding Sign In, Continue, and You must Sign in to continue. to Translation Manager does not translate the built-in Ignition Perspective login page. On 8.0.3 build b2019070502, that page belongs to the identity-provider authentication flow and cannot access the translation state used by an active Perspective session. The same limitation was reported for 8.1 and 8.3; use browser translation or a suitably localized third-party identity provider when a translated sign-in experience is mandatory.
Symptom interpretation
The defining symptom is a translated Perspective project followed by an English login page. Translation Manager can contain exact matches for every visible login phrase while the authentication page remains unchanged.
| Observation | Interpretation | Next check |
|---|---|---|
| Session views translate, but the login page does not | Project translation is operating; the remaining text is outside the session translation context | Confirm that the untranslated page is the built-in identity-provider login page |
Sign In, Continue, and You must Sign in to continue. exist in Translation Manager |
Adding more copies of those terms will not cross the authentication boundary | Stop editing translation terms and select an authentication workaround |
| Browser translation changes the login text | The browser is rewriting rendered content independently of Ignition translation resources | Test the result against the required browsers, languages, and security policy |
| A third-party identity provider displays localized prompts | Localization is being supplied by that provider, not by the Perspective session | Verify locale selection, redirects, error pages, and sign-out behavior |
Do not diagnose this symptom as a missing dictionary entry until a protected Perspective view has been tested after authentication. If ordinary session content also remains untranslated, troubleshoot the project locale and translation configuration as a separate fault.
Identity-provider boundary
The term identity provider here means the component that establishes the user's authenticated identity before the protected Perspective session becomes available. The login page executes in that pre-session authentication context. Perspective session translation depends on state associated with the session, including the locale that selects translated terms.
This ordering creates the limitation: authentication must finish before the normal session state is available, but the login prompt must render before authentication finishes. Translation Manager entries used inside views therefore do not automatically become resources for the identity-provider page. Matching the visible English text does not alter which subsystem owns or renders it.
The limitation also explains why modifying a project view, changing a component binding, or adding session startup logic cannot translate the built-in prompt. Those mechanisms execute within, or in support of, the Perspective session. They do not replace the earlier authentication surface.
Diagnostic checks
- Identify the page owner. Open a protected Perspective resource while signed out. If the untranslated text appears before the project session opens and presents the authentication controls, classify it as the built-in identity-provider page.
- Separate login text from project text. Complete authentication and inspect a view containing a known translated term. If the view changes with the selected locale while the login page remains English, the translation system is functioning inside its intended session boundary.
-
Confirm the installed release. Record the version and build from the gateway before choosing a remedy. The reported installation used
8.0.3buildb2019070502, and later status indicated no different login-translation behavior between8.1and8.3. - Inspect the authentication path. Determine whether the application uses the built-in page or redirects to a third-party identity provider. A redirect moves responsibility for login localization to that provider.
- Define the required locale source. Decide how the pre-authentication page can know the language: browser preference, provider-side user data, a tenant setting, or an explicit language selector. A session locale cannot drive a page that renders before the session exists.
Workaround procedure
Choose the workaround according to who must control the language. Browser translation is the lowest-effort option, but it depends on browser capability and user settings. A third-party identity provider is the engineering choice when the organization must own translated labels, authentication errors, recovery prompts, and locale selection.
- Freeze Translation Manager changes for the login page. Retain the entries if project views use them, but do not treat them as a fix for the built-in authentication page.
- Select the localization owner. For browser translation, document supported browsers and user configuration. For a third-party identity provider, confirm that its hosted login experience supports every required language and the intended locale-selection method.
- Configure the authentication route. Direct the Perspective authentication flow through the selected identity provider when provider-managed localization is required. Use the provider's supported configuration rather than attempting to overlay or rewrite the built-in page.
- Localize the complete authentication journey. Configure the sign-in prompt, validation messages, failed-login response, account-recovery path, and sign-out page. Translating only the initial button leaves operational errors in the wrong language.
- Test without an existing session. Sign out, remove stale authentication state through the normal browser controls, and start from the protected Perspective URL. This reproduces the actual pre-session path.
- Repeat for each required locale. Test the locale source that will exist before authentication. Do not use a locale retained only inside a previously established Perspective session as proof.
Verification readings
-
Check 1: built-in page baseline. Expect Translation Manager entries for
Sign In,Continue, andYou must Sign in to continue.to leave the built-in login page unchanged on the affected behavior. - Check 2: session translation. Expect a known translated project term to appear in the selected language after authentication. Failure here identifies a separate session-localization problem.
- Check 3: pre-session locale. Expect the selected workaround to choose a language before a Perspective session opens. If the language changes only after login, the authentication surface is still not localized.
- Check 4: negative authentication path. Expect an invalid credential attempt and related prompts to remain in the same selected language. Mixed-language errors indicate incomplete provider or browser translation coverage.
- Check 5: clean-session repeat. Expect the same language after sign-out and a new authentication attempt. A result that depends on an old session locale is not a valid pre-authentication fix.
Recurring implementation pitfalls
| Wrong practice | Why it fails | Correct action |
|---|---|---|
| Adding more literal login phrases to Translation Manager | The identity-provider page does not consume the normal Perspective session translation state | Use those terms for session content only |
| Treating a release upgrade as the localization procedure | The limitation was still reported across 8.1 and 8.3
|
Verify the installed release behavior directly and plan an explicit workaround |
| Testing while already authenticated | The test bypasses the page that has the problem | Start signed out from a protected resource |
| Calling browser translation an application translation | The browser controls the rewrite, language coverage, and presentation | Qualify each supported browser and locale separately |
| Localizing only the successful sign-in path | Failures, recovery, and sign-out can expose untranslated identity-provider pages | Test the full authentication lifecycle |
FAQ
How do I translate the Ignition Perspective login page?
Translation Manager cannot translate the built-in identity-provider login page under the affected behavior. Use browser translation or route authentication through a third-party identity provider that supports the required locales.
How do I make Sign In and Continue use Translation Manager?
Adding Sign In and Continue creates project translation terms, but it does not connect the built-in login page to session translation state. Use the terms inside Perspective session content, not as a login-page remedy.
How do I localize the login page before a session exists?
Select a pre-authentication locale source such as browser preference, provider-side data, or a language selector supported by the third-party identity provider. The choice must be available before Perspective creates the authenticated session.
How do I know whether upgrading to 8.3 fixes login translation?
Do not treat the upgrade alone as the fix: the reported behavior did not differ between 8.1 and 8.3. Test the built-in page on the exact installed build before removing a working localization workaround.
How do I verify the localized authentication flow?
Start signed out, open a protected Perspective resource, select each required locale, test both valid and invalid credentials, sign out, and repeat. Expect the login prompt, errors, recovery path, and next clean sign-in to remain in the selected language.