You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Keyman 14.0 - 18.0 have a dependency on /keyboards which means that we cannot rewrite URLs there when we are in 'embed' mode for those apps. The apps check if the URL starts with /keyboards, and handle those paths internally, while opening other URLs in an external browser.
not Url.StartsWith('keyman:') and// don't capture keyman:*
not IsLocalUrl(Url) and// don't capture the external frame or its resources
not TRegEx.IsMatch(Url, UrlPath_RegEx_MatchKeyboardsGo)); // don't capture the launch url https://keyman.com/go/windows/download-keyboards
keyman.com:
/.htaccess
/go/.htaccess
search.mjs
Head.php: remove invalidLocale redirection - see below
Locale.php: remove general locale fallback - see below
We should split this dependency out so that the apps have a private path on keyman.com for presenting the keyboard search. This could be e.g. under /go/app/keyboards/ or similar. For forward-compatibility, we should continue to use url rewriting to avoid reference to .php in the URLs. We should probably match the /keyboards/ paths and could consider avoiding the /keyboards/h/ home pages?
Ideally if /go/app/keyboards was loaded in a non-embedded context, detect and redirect to /keyboards.
Lang and platform should be parameters for the paths contained here.
For unsupported locales coming from apps, we want to redirect to an appropriate fallback locale (e.g. es-es --> es). This is the only place we want to do fallback at this point -- if any other URL has an unsupported locale, we should redirect to /en for now.
Note that site entry should use a browser-lang-based algorithm for selecting the initial locale, but that's a separate project.
Keyman 14.0 - 18.0 have a dependency on /keyboards which means that we cannot rewrite URLs there when we are in 'embed' mode for those apps. The apps check if the URL starts with /keyboards, and handle those paths internally, while opening other URLs in an external browser.
keyman/android/KMAPro/kMAPro/src/main/java/com/tavultesoft/kmapro/KMPBrowserActivity.java
Line 48 in 4ffabeb
keyman/developer/src/tike/project/Keyman.Developer.UI.Project.UfrmCloneKeymanCloudProjectParameters.pas
Lines 198 to 203 in f2f3e32
keyman/ios/engine/KMEI/KeymanEngine/Classes/UniversalLinks.swift
Lines 21 to 81 in ff60148
keyman/linux/keyman-config/keyman_config/downloadkeyboard.py
Lines 87 to 105 in 596371d
keyman/mac/Keyman4MacIM/Keyman4MacIM/KMDownloadKeyboard/KMDownloadKBWindowController.m
Lines 47 to 59 in e5820f5
keyman/windows/src/desktop/kmshell/install/UfrmInstallKeyboardFromWeb.pas
Lines 129 to 142 in 653cb3b
We should split this dependency out so that the apps have a private path on keyman.com for presenting the keyboard search. This could be e.g. under /go/app/keyboards/ or similar. For forward-compatibility, we should continue to use url rewriting to avoid reference to .php in the URLs. We should probably match the /keyboards/ paths and could consider avoiding the /keyboards/h/ home pages?
Ideally if
/go/app/keyboardswas loaded in a non-embedded context, detect and redirect to/keyboards.Lang and platform should be parameters for the paths contained here.
For unsupported locales coming from apps, we want to redirect to an appropriate fallback locale (e.g. es-es --> es). This is the only place we want to do fallback at this point -- if any other URL has an unsupported locale, we should redirect to /en for now.
Note that site entry should use a browser-lang-based algorithm for selecting the initial locale, but that's a separate project.
Relates-to: