variant localisations not used in generation mode

[jonorthwash]

Currently kaz_Cyrl and kaz_Arab have English, Kazakh, and Kyrgyz localisations in https://github.com/apertium/apertium-apy/blob/master/language_names/variants.tsv .

However, these variations never make it to the interface:

[sushain97]

Does the associated APy endpoint serve those language names? This sounds more like a configuration/server issue than anything in the code.

On Mon, May 25, 2020, 10:31 PM Jonathan Washington notifications@github.com wrote:

Currently kaz_Cyrl and kaz_Arab have English, Kazakh, and Kyrgyz localisations in https://github.com/apertium/apertium-apy/blob/master/language_names/variants.tsv .

However, these variations never make it to the interface: [image: screenshot 2020-05-26_01-30-19] https://user-images.githubusercontent.com/963849/82863585-7fb30600-9ef0-11ea-99e5-830fa763565d.png

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/apertium/apertium-html-tools/issues/372, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAEI7S2NDC7AIZ7OHLVRGLRTNH2BANCNFSM4NJ7REEQ .

[jonorthwash]

Does the associated APy endpoint serve those language names?

It does not, despite them being in the database. Several other recently added language names are behaving the same way.

This sounds more like a configuration/server issue than anything in the code.

The problem is apparently (at least according to @TinoDidriksen) because the database is not being rebuilt when packaging happens, which is apparently because of https://github.com/apertium/apertium-apy/issues/148.

[sushain97]

That sounds right.

As I mentioned on IRC, this problem could be avoided by using the Docker images that are built automatically for all merges to master (and block pull request merging if they fail): https://hub.docker.com/repository/docker/apertium/apy. This is how I had beta.apertium.org set up.

Regardless, I think this issue is at best not in the right repository and at worst a dup of apertium/apertium-apy#148.

[jonorthwash]

Yes, it turns out it's essentially a duplicate of that issue.

And yes, I was already using docker images as you described—that wasn't the problem. The problem was that the debian packages weren't building... Anyway, all works now.

[sushain97]

I don't think you were using the docker images I described. If you were, the problem would be entirely moot since the docker image I linked to does not use the Debian packages.

[jonorthwash]

No, I wasn't using that image—I went with an image that uses and updates nightly packaging, at @TinoDidriksen's recommendation.

[sushain97]

Right. And that image will always have the potential of not working with master of apertium-apy by construction (unless the apy travis build is improved). Using the base layer that I recommended will not have this issue.