[freedict] Re: Removal of wikdict dictionaries

  • From: Einhard Leichtfuß <alguien@xxxxxxxxxxxxx>
  • To: freedict@xxxxxxxxxxxxx
  • Date: Sun, 1 Apr 2018 16:16:17 +0200

Hi,

On 2018-03-29 23:27, Sebastian Humenda wrote:

Hi

Before, I only packaged the vcs version of the tools, though today I
tried to package those on sourceforge.net. Unfortunately, they appear to
notably lag behind (version 0.4, 2014-03-02) and don't work for me (I
tried the current non-vcs versions of deu-eng and eng-spa).
I sent you the GitHub link. Our website points to GitHub and the SourceForge
site should mention that we have moved. Whatever you find on SourceForge is
outdated. Is there a way we can make that even more clear?

But the dictionary sources themselves on SourceForge are not outdated?
At least they are referenced from the "Detailed list", the json and the
xml file.
We used SF as a data store, because we couldn't find something appropriate
quickly enough. This should change in the next month.

Even though I for myself will be notified by a script parsing the json
file upon any such changement, I believe it would be a good idea to
announce such changes here, or on a separate -announce list.

Please try this:
https://github.com/freedict/tools/releases

Thanks. I just thought all the non-vcs sources (i.e. releases) were to
be searched for on SourceForge. It would be great if, on the website,
there was a short description how to work with the release files,
Could you have a look at neu.freedict.org, please? This is our new draft of 
the
website. If you find this information not there, let us know.

I do like the new website. Clean and simple.
Though, I will note a few things I consider worth an improvement:

- Documentation.
  That is basically what I was asking for. Though, in the getting
  started section I'd expect a note on where to get the sources;
  that they may be got from either GitHub or by using the API, described
  later and hence linked downwards. Instead, one might consider to
  change the reference to the download page in the paragraph above to
  also note, that sources may be found there as well. Also, a separate
  "Getting Sources" paragraph might be an idea, though that seems a
  little overdone for basically a link to the downloads page.

- Downloads.
  I generally would like the individual source files also being
  presented. As they were on the old website.
  Furthermore, you only mention GoldenDict. Maybe another link towards
  your list of clients, like on the documentation page? Actually I
  thought, dictd in combination with some client was the most common
  option. As far as I know, GoldenDict doesn't use dictd, however your
  make install target attempts to interact with dictd (see later note on
  that).
  Lastly, I personally do not like those drop-down menus, particularly
  due to them apparently requiring javascript. Though the table on the
  old website grew admittedly quite large. Also, and more importantly,
  choosing language A will only show A-X entries, not X-A ones. For some
  reason I believe, I'd prefer two drop down menus, one for the first
  language and one for the second, where the second's options get
  updated, ore rather active at all, once the first option is chosen.
  Still, I would like to see also the inverse dictionary being
  presented, if available, of course. If only the inverse dictionary B-A
  was available, it should in my opionion also be findable searchin for
  A-B.
  Oh, and given the fact that your dictionaries are packaged for some
  GNU/Linux distributions, it might be worth noting that one should
  check first, whether one's distribution offers them, maybe even
  listing a few. Those I package are in the AUR only, i.e. non-official,
  though.
  Also, in the Source and API section, I'd note not only the source but
  also the binary files being listed in the API files.

- General.
  The link(s) to view the site in another language currrently redirect
  to the home page. I'd prefer them to point to the translation of the
  currently visited page.


A note on the Makefile (tools/mk/dicts.mk)
- As noted above, the install target attempts to restart dictd. I do not
  consider that a good idea. Particularly, it won't have the desired
  effect (on Arch at least), as restarting dictd does not add the
  dictionary files to dictd.conf.
  Also, there may be reasons not to restart dictd, e.g. when installing
  many dictionaries at a time, since restarting dictd (at least using
  systemd) several times in a row may make it fail.
- Also, I'd like documentation files being copied by `make install'. I
  currently do not use `make install' in my packages, but instead
  manually copy the files, including any of AUTHORS, README, NEWS,
  ChangeLog, if existing.


Other stuff.
- Checksums are great. Maybe you could provide such in the API?
  Currently, my script fetches the sources / binaries on every update,
  just to calculate the checksum.
- In the "list of clients" on GitHub, I miss the mention of `dict',
  being part of dictd itself, as far as I know. In my eyes, the most
  straightforward option.
  Also, the XFCE4 dictionary [0] may be considered worth including.



information on all (or most) installation (and bulding) options.
Building options are explained in the Wiki, I'm not sure how to present that 
on
the Website without duplicating content.

I'm fine with that.

[...]

By the way, another thing I just noticed: The website by default
redirects me to /ru/. That did not happen the last time. I presume this
is not intended, in particular, it is not possible to choose English
from the list. Manually entering the /en/ URL works, though.
Err, that is weird indeed. Another good reason to speed up the website
migration.

The problem with the missing .index file in the tar archives is fixed now.

Great, thanks!


Greetings,
Einhard



[0] https://goodies.xfce.org/projects/applications/xfce4-dict

Attachment: signature.asc
Description: OpenPGP digital signature

Other related posts: