Rename "novid" to "no_videos" in zim file names

[Popolechien]

We've had quite a few people asking what the difference between "all" and "novid" was, so I guess the current state is not self-explanatory.

[tim-moody]

The problem is also that the attribute "all" is overloaded in that it really means all content, as opposed to "medicine" or some other filtered content, not all media types as opposed to novid or nopic.

[Jaifroid]

It's not too hard to guess what novid means. On the other hand, I haven't a clue what nodet means... (I know there's an issue for that). If you change novid to something else, I wonder if it should be no-video (using a hyphen) or novideo, because semantically the underscore in the filename titles seems to separate important "categories" of information about the type of ZIM. So, we have: wiki type _ language _ content set _ scope of content _ date . zim. The descriptor novid, or no-video comes under scope of content.

[kelson42]

It is impossible (to many things to say) to make a ZIM file which is properly explaining the content. On the top of this a ZIM file could be changed. to the contrary to the ZIM content. So it is really a bad idea to rely to the filename to do so. The solution we have, and I want to stick to, is the tagging system... and in it there is a "novid" tag. Considering the fact that these tag should not be changed every days (people might rely on it) and that "novid" is relatively self-explaining, I tend to think that the Kiwix reader should just display something more readable if it see it. This is what is done for example on Kiwix IOS. So I would close this ticket (and maybe create one for the Kiwix port concerned by the pb).

[Popolechien]

If novid was so self-explaining we wouldn't have people coming over asking what it means. Remember that a fair share is non- or poor- English speaking, and that "novid" as a word, without context, is really lacking in info. It would not hurt to at least rename it to "no-video".
(I agree with the rest of your discussion and tagging really is the way forward; but until then, that could be a quick win).

[kelson42]

@Popolechien You say it, it is impossible to have 100% success on this - simply because not all people can speak English. So, you need to have something on the reader side to localise it, make it clear to users.

[tim-moody]

@kelson42 I understand that these tags are now legacy and not easily changed, however, I would have preferred positive rather than negative tags such as has_videos, has_audio, etc. as such tags are more extensible. Today no tag means has videos, but that was not true in the past and might not be true in the future.

[Jaifroid]

Whatever is decided, please try to avoid using an underscore in the tag name, because as I mentioned above, the underscore currently separates useful info categories in the filename, and I actually rely on that in Kiwix JS Windows, to parse bits of the filename for filtering ZIM files on the server. A hyphen would be fine, just no underscrore please!

[kelson42]

@tim-moody I have open a specific ticket about your long standing request on this. Hope this is more or less what you meant. See #485

[kelson42]

@Jaifroid This is really a weakness in the reader IMO. Not a problem with the content.

[Jaifroid]

@kelson42 My scenario is that the software allows the user to select a file to download from the Kiwix ZIM-file server and offers to filter the masses of files based on language, date, content-type, etc. Since the files are on the server and not yet downloaded, the only info the software has about their contents is what is encoded in the filename. Hence, it's helpful, and simplifies the code, if the filename is logically and predictably structured (which it currently is).

[tim-moody]

@Jaifroid have a look at https://github.com/iiab/iiab-admin-console where I do the same. I use the kiwix catalog to get the meta data rather than parsing the name. (except that I distinguish between the generic name like wikipedia_en_all vs the instance name like wikipedia_en_all_2018-10 which I have to parse)

[Jaifroid]

@tim-moody Very helpful, many thanks! I'll take a look.

[kelson42]

We have decided to simplify the offering that way. This makes this ticket invalid.