Open benoit74 opened 6 months ago
For the record we got permission for the folks at lowtechmagazine to reproduce their content https://kiwix.freshdesk.com/a/tickets/70236
For now, I've updated the recipe / ZIM Name to properly indicate that it is a mul
file and which languages are present inside the file.
For now, I've updated the recipe / ZIM Name to properly indicate that it is a
mul
file and which languages are present inside the file.
Seems like the best interim solution, especially for useability. Personally I think we shouldn't assume all our readers are monolingual. They may prefer to read articles in, say, Polish, but given a choice between no article or an article in French or English (because only a small number of articles have been translated to Polish), what would be most useful to them? I know what I would prefer!
I strongly disagree - the mul
tag allows the file to appear in target languages but as a French speaker nowhere on the English front page do I see how or where I could get that resource in my language (my browser's default language is set to French but the zim did not pick it up)
Some articles offer translations, some don't, but there is no way to know until one has poked around. I opened a random article that had translations, picked to the language of my choice, and then only could loop back to the German front page. Nobody is ever going to do this.
my browser's default language is set to French but the zim did not pick it up
That sounds like it is more a problem of the Website's poor multilingual support. I haven't downloaded the mul
archive, only the one labelled as English, but don't you see the dropdown below on the front page when you click the globe icon? -
Ah my bad on that one. But my point still stands: do we want people to download X Gb of data (which has/is a cost) when only a fraction is useful to them?
I still consider we need to split the ZIM. The mul is only the short term update just meant to reflect current reality : the ZIM contains not only English but many more languages. On the medium term, we need to at least try to split the ZIM. Maybe providing both the mul and the language specific ZIM is the proper solution since the sheer size of the ZIM for English and French is probably the images, so their size might be close to the mul size, but this is probably not true for less translated languages (not sure which percentage of articles are translated per language).
As mentionned in https://github.com/openzim/zim-requests/issues/1023, current ZIM contains all supported languages which is not inline with our practices where we prefer to have one ZIM per language.
We should hence split the ZIM / recipe with one per language:
/en
path prefix in the URL, so either we list all current other languages - fragile - or we suppose that anything in the first portion of the path which is 2 alpha long is a language - fragile again)