keymanapp / keyman.com Goto Github PK

On this page: https://keyman.com/developer/download.php
We have the option to download the compiler, but nothing is said about it or why you would need to download it.

A little explanation on the page would be helpful.

Per Doug Higby

"Thanks for all that you have done to facilitate keyboarding in languages with “unconventional” characters. Keyman is a phenomenal product — Kevin Warfel, SIL/JAARS"

Found near bottom of home page

upload diagnostic report is failing with version 13 of Keyman Desktop. Also, want to validate that it is working with earlier versions!

Three of the buttons in the keyman.com keyboard landing page are shown as "Install" instead of "Download" since they are not installable on the current devices/platforms keyman.com is being browsed on. (See the screenshot below)

Some keyboards tagged with multiple BCP-47 codes are not listing in https://keyman.com/keyboards when searching with language name.

For Example, Malar Braille keyboard and Devanagari Phonetic (SIL) keyboard are listed for language with BCP 47 code 'hi'. But these keyboards are not listing when searching for language name 'Hindi'.

From Language Software Community forum where a user requested the SIL IPA keyboard to appear higher in keyboard searches

Reply from @mcdurdin

These are returned in alphabetical order in the keyboard search.
I'd like to include a shortcut at the top when one searches for "IPA" with a link to the https://keyman.com/ipa/ page whcih is a dedicated home page for IPA keyboards...

This seems to be a change in recent release of Chrome, perhaps?

https://keyman-staging.com/keyboards/install/khmer_angkor will show the keyman: url prompt but also start the download of the installer.

Firefox 81.0.2: works correctly.

New SIL International Language Software Privacy Policy and SIL International Language Software Terms of Use documents posted.

Privacy Policy

• keyman.com
• help.keyman.com
• keymanweb.com
• Google Play Store listing

Terms of Use:

• ???

@markpenny would like to see deprecation info on keyboard search results to help users make a better decision which keyboard to install. (e.g. which SIL IPA keyboard to get?)

Direction from @mcdurdin

The search currently doesn't publish deprecation information in the search results but it does in the individual keyboard information. Two possible fixes:

1. Show a 'deprecated' flag next to deprecated keyboards. What should that deprecated flag be? Probably a red box next to the title says something like [ Old version, replaced by sil_ipa ], and clicking the red box would take you to the new keyboard.
2. Don't show deprecated keyboards by default.

I think the 'deprecated' flag is actually better because if people are searching for a familiar keyboard, or if the only result shown is for a deprecated keyboard, navigation to the replacement becomes clear.

Obv we don't use the term 'deprecated' in the UI because it's a weird word for many users.

2. is related to #177

On the main page footer with many language names, Chrome is rendering "Rawang" as

even though it's Latin characters in an raw span.

This renders fine on Safari and Firefox

Right now, most of the dedicated landing pages still focus on Windows, although the keyboards contained mostly work on all platforms. Furthermore, we have not really tested them for responsive layout.

This should be completed prior to 14.0 release, because the landing pages will appear in the keyboard search results in embedded searches.

Eventually, links to tavultesoft infrastructure will need to be removed.

Some of them are:

• Several featured keyboards redirect to tavulesoft
• downloads/archive/ references self-service manual activation

more to be added later...

Describe the bug
keyboard_info says you can insert "links" as described in the documentation:
https://help.keyman.com/developer/cloud/keyboard_info/1.0/

To Reproduce
Steps to reproduce the behavior:
1a. Go to https://github.com/keymanapp/keyboards/blob/master/release/g/gandhari/gandhari.keyboard_info - you can see the syntax I used.
1b. Go to https://github.com/keymanapp/keyboards/blob/master/legacy/g/gandhari-keyboard-2.7/gandhari-keyboard-2.7.keyboard_info - this page has numerous links
2a. Go to: https://keyman.com/keyboards/gandhari - you can see that no links are displayed on the keyboard home page.
2b. Go to: https://keyman.com/keyboards/gandhari-keyboard-2.7 - none of the links are displayed.

Expected behavior
I would expect the link to show up in a section on links, just as "related" keyboards show up, etc.

If this is no longer a desired use in keyboard_info, the documentation should be adjusted.

I did a scan through the site and found the following things that we should consider addressing for release:

• keyman.com/desktop/features
  • shows an 11.0 splash under "easy setup"
  • "Technical Support" - shows some version info
  • "Used by Biggest" - should we really be showing SIL as a big-name user now?
  • The CSS seems a bit off at the top
• keyman.com/desktop
  • final Q - add "11.0" mention
• keyman.com/developer
  • CTRL+F 'respository'
• keyman.com/developer/features
  • Same CSS thing as /desktop/features
  • First left-hand menu jump target is off
  • Broken links to bcp47-tags
• keyman.com/mac
  • are the known issues still current?
• keyman.com/linux
  • Q: install a Keyman keyboard
    • Issue: help.keyman.com link is wrong. Missing a /guide/ in the path!
• keyman.com/iphone-and-ipad
  • Should we still keep the "now free" bit?
  • Second link from bottom - iphone instead of iPhone.
  • Version history link is off.
• keyman.com/android
  • Version history link again.
• keyman.com/downloads/archive
  • Will need to add last stable 11.0 versions here
• keyman.com/testimonials
  • Most recent testimonial is from mid-2012. Yikes.

The issues noted with the CSS above also affect (at minimum) the current 11.0 version of the pages.

I noticed while testing a recent PR that keyman.com's page-width test to determine the menu type to display has an interesting issue if you cross the threshold while the menu is displayed:

Just a few pixels wider:

Also, in this situation, it is impossible to dismiss the menu without shrinking the page again (so that the menu 'hamburger' reappears and can be used for dismissal). While the 'desktop'-aimed hover menus do appear to function in this state, they aren't very usable - the phone menu hides them.

We are getting inconsistent results when searching for languages.

If we search for a language name, like "Tagalog", we see "Tagalog" showing up.

If we search for a language code, like "tgl", see the language name PLUS a dialect name (like "Tagalog (Bataan)"). This is undesirable as the iso code does not actually refer to a specific dialect. In this case, it's just using the first dialect alphabetically and is not based on most common dialect at all.

My view: I'm assuming you are using a list from the Ethnologue and it's finding the first dialect alphabetically. I wonder if we should be using a different list of just the languages -- and not
the dialects. Since we cannot select a dialect in Keyman, I don't think we should display the dialects on keyman.com.

However, I realize there are competing requirements.

While we don't really support IE any more, legacy edge is still fairly present. We should avoid trying to trigger the keyman: protocol on legacy edge/ie and just let the user download the bootstrap installer instead.

Goes with keymanapp/keyboards#337

In LDML we need to provide a stable URL to the latest kmp. keyman.com/download seems the most appropriate mechanism for this, but it seems to require a platform which we don't want to have to specify in an LDML file.
It doesn't really matter what the URL of the kmp ends up being so long as it is stable.

For example, try visiting https://staging-keyman-com.azurewebsites.net/go/package/download/foobar?platform=ios&tier=alpha&bcp47=km&update=1.

What I expected: a 404 or similar error code.

What I got: "Invalid parameter; id not found" (likely from a PHP error), 'success' HTTP header.

Per https://twitter.com/keyman/status/1209946675629842432, the information on keyman.com/mac is out of date for if() statements. See also corresponding keymanapp/help.keyman.com#97

Describe the bug
The pagination for popular keyboards goes missing once hit page 6 and beyond.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Configuration'
2. Click on 'Download keyboard...' and then "Popular" link in the description
3. Scroll down to the bottom of the page and click on number 6 or greater
4. See error at the bottom of the page

Expected behavior
If there is an option to click on, the pagination should be visible all the way.

Screenshots
The pagination should be shown at the highlighted area:

Keyman Desktop:

• OS: Windows 10 Pro 2004
• Keyman version: 14.0.168-alpha
• Target Application: [self]

Related to keymanapp/keyman#4247

On an Android device with Keyman for Android 14.0- beta installed,
Opening the external Chrome browser to https://keyman-staging.com/amharic and try to install the amharic keyboard.

The staging site is generating a link
keyman://localhost/open?keyboard=gff_amharic&language=am

But the app won't download because it needs to match a regex keyboards/install

Per @mcdurdin

We can always change the website to point to the .kmp, can't we? After release of 14.0 anyway...

We might want the 14.0 app to handle the legacy link though.

One last broken link:

Getting links from: http://localhost:8888/keyboards/gff_geez
├─BROKEN─ http://localhost:8888/keyboards/gff-gez-7 (HTTP_404)

I don't want to solve this one just now -- it involves making that a non-link on the page as it is an obsolete keyboard not listed on the site.

Originally posted by @mcdurdin in #194 (comment)

Keyboard Package Downloads
Apps should download all packages from cloud using the following link pattern:

https://keyman.com/go/package/download[/type]/package_id?[version=package_version][&platform=platform][&tier=tier][&bcp47=bcp47][&update=0|1]

All parameters are optional. platform, tier, bcp47 and update are used for analytics only.

• package_version: the version of the package to download. If not specified, the website will look up the latest version from downloads.keyman.com/api/keyboard and use that.
• platform: one of android, ios, linux, macos, windows.
• tier: one of stable, beta, alpha. If not specified, assumes stable. This should be retrieved from the version of Keyman that is installed.
• bcp47. A valid BCP 47 tag that is being associated with the keyboard. Typically used only for new installs.
• update. If 0, reported as a new download (e.g. from a bootstrap installation). If 1, then this is reporting upgrade of an existing package. If not present, defaults to 0.
• TODO: type: one of keyboard, model. If not specified, assumes keyboard.

See also keymanapp/api.keyman.com#102 for related work

For example, see https://sentry.keyman.com/organizations/keyman/issues/896/?environment=production&project=3&referrer=alert_email

This seems to ignore Back from search result to new search page and is probably related to the inline url search pattern.

When a keyboard search isn't found, I'm not sure we want to display the PHP errors

Rather than returning all keyboards, it should return only the top 10 or 20.

Then, another custom search should return all keyboards alphabetically (for search engine indexing purposes if nothing else).

https://https//blog.keyman.com/!

For example, the Install Keyboard link at https://keyman-staging.com/keyboards/install/sil_euro_latin?bcp47=fr&tier=alpha does currently work, but https://keyman-staging.com/keyboards/install/khmer_angkor?tier=alpha gives a broken pattern without a .exe suffix.

Click on the link read "help.keyman.com" highlighted above leads to this:

We have the monthly download stats in the search; they should be visible on the keyboard landing page as well.

@sewhite writes

Would it be possible to have the page describing a keyboard display or have a link to the list of language tags that the keyboard is valid for? For instance, Lorna just pasted a link to the github repo listing the BCP 47 tags for the Libtralo keyboard. Could this link be on the keyboard description page?

From https://community.software.sil.org/t/suggestion-for-keyman-keyboard-listings/1196

I (Darcy) wonder if we can add it to the "Keyboard Details" section in keyboards/keyboard.php.

Now that KAB is available, we should link to it in the Keyman Engine for Android information, and also possibly in the documentation to let devs know of another option for building keyboard apps.

• /desktop needs to redirect to /windows
• Update internal links
• Refresh content throughout (taking care not to break earlier versions of Keyman Desktop)

When in embedded mode, the [Install] button should not be available if a given keyboard is not available for that platform.

For example, in Keyman for Windows, navigate from sil_ipa result to ipauni11. This keyboard is web-only and should not really be made available to Windows install.

Related: ipauni11 result shows 'package download' link but has no package. This should not be made available as a link (it's deprecated which is why there is no package).

From embedded keyboard search on the staging site, I'm getting console exceptions with the following:

Chrome mobile viewport (Pixel 2)

1. Go to https://staging-keyman-com.azurewebsites.net/go/android/14.0/download-keyboards
2. Search for "khmer_angkor"
3. On the result page, click on "khmer_angkor"
4. This loads https://staging-keyman-com.azurewebsites.net/keyboards/khmer_angkor but with the console exceptions

search.js:282 Uncaught TypeError: Cannot read property 'q' of undefined
    at init (search.js:282)
    at load_search (search.js:311)

When searching for a keyboard, a dropdown menu may appear if you have search for some keyboards previously. The bug happens when the mouse pointer is moved to click on the desired keyboard--the menu disappears all of a sudden.

In the screenshot below, the user is trying to look for a language begin with "k" and the list appears, but when moving the pointer to "Khmer," the menu is gone leaving nothing to choose from.

When a desktop browser is full-screen, the top-menu1 toolbar works fine (on-hover).
When the browser is resized small enough and the page refreshed, the toolbar becomes a hamburger menu that's un-clickable.

On a mobile device, the same hamburger menu responds fine to touch

We do this in the help.keyman.com ci, so copy this to the keyman.com ci

On keymanweb.com, we can save a bookmarklet for
https://keymanweb.com/#th,Keyboard_basic_kbdth0

But on https://keyman.com/bookmarklet/ (also the staging site), the Basic Thai keyboard doesn't appear in the list of bookmarklets.

Right now, the website refers in a few places to keymandesktop-a.b.c.d.exe but we should change the pattern when we go to stable to the new keyman-a.b.c.exe.

At least some of these changes have a TODO against them in the source referencing this issue number #186.

The banner should not be hidden when the rest of the content is hidden. e.g. on page https://keyman-staging.com/keyboards/galaxiebiblescriptmnemonic

The banner shown here should be visible in the initial page load:

On the staging site, the header and footer for Eurolatin look duplicated
https://keyman-staging.com/keyboards/h/eurolatin/

There's also an extra banner before the keyboard details

Header(s)

Footer(s)

Redirects to https://keyman.com/keyboards/dlia25bas instead of https://keyman.com/keyboards/el_dinka

When working with the embedded search, links outside the /keyboards path are intended to open in an external browser. However, the dedicated landing pages are all currently hosted in the / path.

Propose moving the landing pages to /keyboards/h/ as a future home for all keyboard landing pages. This would then involve updating /web.config to put in redirects for each of those pages. Organizationally, this reduces the level of confusion of the root of keyman.com, and puts dedicated landing pages on the same level as other keyboard redirects such as /khmer.

This also relates to #174.

Is your feature request related to a problem? Please describe.
I'm always frustrated when making an attempt to follow the suggested hints.

Describe the solution you'd like
It would be helpful if examples for each use case can be provided.

Describe alternatives you've considered
Probably describe how to use those "prefixes".

Product context

• OS: Windows 10 Pro 2004

Additional context
Is this the right way to use the BCP47 prefix: