search

keymanapp / keyboards

Open Source Keyman keyboards
152 stars 276 forks source link

[infrastructure] Add all .js keyboards to package #337

Closed darcywong00 closed 4 years ago

darcywong00 commented 6 years ago

legacy keyboards

release keyboards

// fv append _kmw for .js files fv_dakelh fv_denesuline_epsilon fv_diitiidatx fv_gitsenimx fv_gwichin fv_halqemeylem fv_han fv_henqeminem fv_hlgaagilda_xaayda_kil fv_kanienkeha_e fv_ktunaxa fv_kwakwala fv_kwakwala_liqwala fv_migmaq fv_natwits fv_nisgaa fv_nlekepmxcin fv_nortern_tutchone fv_nsilxcen fv_nuucaanul fv_secwepemctsin fv_sencoten fv_shashishalhem fv_smalgyax fv_southern_tuchone fv_statimcets fv_statlimxec fv_tagizi_dene fv_taltan fv_tsekehne fv_tsilhqotin fv_uwikala fv_xaislakala

LornaSIL commented 6 years ago

@darcywong00 do you want us to manually do these or do you have a plan for a way to do this with a script?

darcywong00 commented 6 years ago

Hmm, this might be too complicated to do with a script. In addition to adding the JS file to the package, we'd want to make sure applicable font and language tags are associated.

And since we're already editing package files, do we want to add <FollowKeyboardVersion/>? #246

DavidLRowe commented 6 years ago

I suspect that the version number would need to be bumped as well? That shows up in README.md, HISTORY.md, xyz.kpj, xyz.kps and perhaps other places as well.

mcdurdin commented 5 years ago

Note, my audit just now showed the following .js keyboards in legacy that are not yet in packages:

This has become more urgent with the change to the Keyman site to no longer list .js files for download in the apps.

LornaSIL commented 5 years ago

@makara has been assigned 50 of the Windows keyboards and I've got about 36 Windows keyboards left. That's the majority of what you've listed. If he could make them a priority that would be good. I'm planning to complete mine by the end of December if possible.

The others are complicated and may require some discussion after I'm available again. For instance, the kab keyboard author doesn't even want his keyboards listed anymore. It's possible they could be deprecated as they are based on a standard layout that we have other keyboards that support the same layout.

mcdurdin commented 5 years ago

That list I realise isn't complete; there are no doubt packages there that include .kmp and .js where the .js hasn't made its way into the package.

mcdurdin commented 5 years ago

Yep. I think many of the KAB keyboards could probably be marked deprecated. Or we could remove them as many of them are not really in use (gosh it would be good to be collecting usage stats... task for another day)

mcdurdin commented 5 years ago

I expect many of these keyboards are not really used. But we just don't have the stats to know at this point :(

LornaSIL commented 5 years ago

If you have a way to get stats let me know. Otherwise, I can use the spreadsheet from 18-24 months ago to prioritize. But, I'm not expecting to be able to work this week. I may start working for short periods the following week.

mcdurdin commented 5 years ago

We don’t currently collect the stats in a useful way. Collecting stats is on our radar.

LornaSIL commented 5 years ago

@mcdurdin you mention this is more important now. I'd like to understand the timing and expectations better. I'm working on them as quickly as I can, but if it's urgent, we will need Makara prioritized to help.

mcdurdin commented 5 years ago

The reason it is more important than previously is that the keyman.com site now only shows the .kmp install link. However, the in-app selector still downloads the old .js version, for now. This will change with version 14.0 -- from there on we will only download .kmp versions.

I could write a script that generated a .kps and thus .kmp, as is, in the legacy folder, to take the pressure off. I don't think it would be a huge amount of work but the results wouldn't be perfect.

By 'perfect', I mean that the metadata would be patchy. They'd still work.

mcdurdin commented 5 years ago

It can be challenging to keep on top of the various requirements for platform support. While the .keyboard_info data generally does a good job, and kmcomp is pretty good at filling in the gaps, the edge cases still sometimes trip me up.

Good news:

Bad news:

LornaSIL commented 5 years ago

we now collect stats on keyboard downloads.

Where can I find the stats? Or is it too new to be useful?

mcdurdin commented 5 years ago

The stats are available through Google Analytics but they've only been going a couple of days... so we should wait a little while to get clarity.

mcdurdin commented 5 years ago

Yesterday's stats (incomplete because we still aren't capturing all of the mobile events -- that will come later):

image

LornaSIL commented 4 years ago

I think these are the remaining 32:

LornaSIL commented 4 years ago

@mcdurdin @darcywong00 for the keyboards we don't have enough information to move to "release"... I added a .kpj and .kps file assuming the build system would build a .kmp. Was that a wrong assumption?

For example https://github.com/keymanapp/keyboards/tree/master/legacy/b/bod | https://keyman.com/keyboards/bod Do I need to actually add the .kmp to the source folder?

mcdurdin commented 4 years ago

Do I need to actually add the .kmp to the source folder?

The 'legacy' keyboards should not have any source files added to them. They are there so we don't lose distribution of them, and they are treated specially -- just a .js or .kmp.

If we add source files, they should either go to experimental, or release, as then they are treated as under maintenance. So in this case, I'd put it in experimental with a note in the readme as to why it's there rather than release.

At distribution point, all three categories are treated identically -- there is no differentiation in the way it's presented to the end user. So while 'experimental' might feel a little weird, I think it works okay.

LornaSIL commented 4 years ago

@mcdurdin

If we add source files, they should either go to experimental, or release, as then they are treated as under maintenance. So in this case, I'd put it in experimental with a note in the readme as to why it's there rather than release.

So, I tried that and the error on TeamCity says Could not find output file build/bod.js even though my kps is calling for source/bod.js. (https://github.com/keymanapp/keyboards/pull/1170)

So, I think I should just commit the kmp into the legacy folder? I don't know what else to try.

If I commit the kmp...do I keep the .kpj and .kps files that I used to create them in the repo, or do I throw them out.

mcdurdin commented 4 years ago

Oh I see -- I thought you were building bod from some source files. My bad. Yes, then in this situation just add the compiled .kmp to the legacy/ folder, and might as well put the .kpj and .kps in as well with a note. Of note here is that we can't (easily) change version number in the .js (and this is worse in the .kmx) so we'll be stuck with the existing version.

LornaSIL commented 4 years ago

Oh I see -- I thought you were building bod from some source files. My bad. Yes, then in this situation just add the compiled .kmp to the legacy/ folder, and might as well put the .kpj and .kps in as well with a note. Of note here is that we can't (easily) change version number in the .js (and this is worse in the .kmx) so we'll be stuck with the existing version.

Do I need to add "packageFilename": "bod.kmp", to the keyboard_info? At least at the time of writing this the bod keyboard isn't showing the .kmp. https://keyman.com/keyboards/bod I really don't know what else to do.

LornaSIL commented 4 years ago

I think these are the remaining 23:

FV

Daniel Yacob:

Andrew Cunningham

mcdurdin commented 4 years ago

Over the weekend I located some old backups and found some additional source files! As usual these may need work... but may help us for deciding what we do with these keyboards. I've messaged a private link to you, @LornaSIL.

DavidLRowe commented 4 years ago

@mcdurdin Can you clarify the timing on this issue? When do these need to be completed (to fit with the deployment of version 14)? @LornaSIL has done most of the ones on your list, but some are waiting on others.

Outstanding keyboards:

mcdurdin commented 4 years ago

The timing for this is linked to the release of Keyman 14, which is scheduled for around the end of this year. Keyboards which are not packaged will not be available for mobile use. So it's not disastrous if a handful of keyboards are not available before Keyman 14 is released; we can always fix them as requested by the community for the less-used ones.

andjc commented 4 years ago

In my case, the keyboards in question were never designed and optimised for touch layouts so will need a complete review and in some cases a redesign.

Will try to get to it soon, but depends on other factors my timelines have been thrown out of wack.

Andrew

On Fri, 10 Jul 2020, 03:25 DavidLRowe notifications@github.com wrote:

@mcdurdin https://github.com/mcdurdin Can you clarify the timing on this issue? When do these need to be completed (to fit with the deployment of version 14)? @LornaSIL https://github.com/LornaSIL has done most of the ones on your list, but some are waiting on others.

Outstanding keyboards:

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/keymanapp/keyboards/issues/337#issuecomment-656253701, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALGM675XOJXI4EXKYVCAU3R2X4RHANCNFSM4FEZEXZA .

mcdurdin commented 4 years ago

@andjc FWIW, this particular issue was not intended to trigger redesign of the keyboards in question to support mobile. This was rather only to ensure that keyboards that support mobile already are repackaged in a .kmp so that they can be installed in Keyman 14.0 or latest versions (as we will be removing support for direct installation of .js keyboards).

andjc commented 4 years ago

I know, but they are layouts I never created mobile layouts for, so would prefer to go through each to see if the existing files are suitable and match desktop versions, or whether more work needs to go into them.

In some cases the js versions are divergent and not a good fit, or reflect older versions of the layout.

On Mon, 13 Jul 2020, 14:40 Marc Durdin notifications@github.com wrote:

@andjc https://github.com/andjc FWIW, this particular issue was not intended to trigger redesign of the keyboards in question to support mobile. This was rather only to ensure that keyboards that support mobile already are repackaged in a .kmp so that they can be installed in Keyman 14.0 or latest versions (as we will be removing support for direct installation of .js keyboards).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/keymanapp/keyboards/issues/337#issuecomment-657354172, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALGM62BP454XIGH5BUSAMDR3KF27ANCNFSM4FEZEXZA .

mcdurdin commented 4 years ago

@andjc no worries. That work can happen independently of this particular effort, which is basically just to maintain status quo. I'd prefer to look at improvements as separate parcels of work, which can happen in a timeframe which works for you and doesn't have to be tied to a release date for Keyman.

andjc commented 4 years ago

Problem is that in certain cases the js file is based on a different version from kmp file and in at least one case may reflect a different orthography. So should not be bundled together.

On Mon, 13 Jul 2020, 15:35 Marc Durdin notifications@github.com wrote:

@andjc https://github.com/andjc no worries. That work can happen independently of this particular effort, which is basically just to maintain status quo. I'd prefer to look at improvements as separate parcels of work, which can happen in a timeframe which works for you and doesn't have to be tied to a release date for Keyman.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/keymanapp/keyboards/issues/337#issuecomment-657368711, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALGM6YFJHZJKEA2C6E4ZVLR3KML3ANCNFSM4FEZEXZA .

mcdurdin commented 4 years ago

@andjc which keyboards are in this situation?

LornaSIL commented 4 years ago

Remaining keyboards listed in #1293