czcorpus / kontext Goto Github PK

e.g. anonymous user displays a concordance then she logs in and then she should be redirected back to the concordance list, not the homepage

In the development version - in case no result is found no message is provided.
Maybe this is more general problem - it must be further investigated.

see the title

flagship corpus will be defined using new XML attribute

see the title

A normal KonText page should appear with some warning.

In given query when you try to go for the page 12/12 with next page button Kontext reports error:
Failed to process your request. Please try again later or contact system support.

https://kontext.korpus.cz/view?q=~mKpaKzXj;fromp=11;corpname=intercorp_v7_cs&usesubcorp=Core+czech&maincorp=intercorp_v7_cs&viewmode=align&pagesize=100&align=intercorp_v7_be%2Cintercorp_v7_bg%2Cintercorp_v7_ca%2Cintercorp_v7_da&attrs=word&attr_allpos=kw&ctxattrs=word&structs=div%2Cs&refs=doc%2C%3Ddoc.id

The thing is we should be able to (optionally) obtain all the data we see in a typical Apache log (IP, user agent, url,...) from a single log - KonText's application log.

1. e.g. there is no "subcorpus" menu item any more
2. in addition, it would be great to make this constant-based to make IDE do the job and prevent possible errors

... because not all of them are needed on all the pages

You can find more in the screenshot attached.

Something like this:

@exposed(http_method='POST')
def foo(req):
  pass

Such method should be invoked iff the request is POST.

see the title

• JavaScript seems to not work properly
• there is a "closed concordance" box visible even if there cannot be any concordance available

how to replicate:

1. use e.g. a corpus of English language
2. search for "are"
3. select multi-level freq. distribution and "position = 1R"
4. display the result
5. find a line containing e.g. the apostrophe character and click either "p" or "n"

... and the full query should be visible on mouseover or something like that

E.g. - if you enter the "view" section without having a concordance active, concordance-related menu items are available which is wrong.

see the title

The corpus selection menu in the English interface is now correctly in English (thanks!), but the mouse hovering action brings out Czech descriptions.

see the title

see the title

... for anonymous users

This means also getting rid of supports_password_change() method.

... and implement a Redis-based solution. This should bring automatic record locking and simplify related code. Current solution should be still available (though as a plug-in).

...e.g. by setting font to italic

Vasek has discovered a strange bug when Kontext behaves a bit differently from NoSkE. Search for "ano" (query type "basic") in ORAL2008, shuffle the concordandce (if not shuffled as default) and then sort according to sp.pohlavi. This will get you to the following screens:

NoSkE: https://korpus.cz/corpora/run.cgi/sortx?q=aword%2C[word%3D%22%28%3Fi%29ano%22]&q=f&corpname=oral2008&attrs=word&attr_allpos=kw&ctxattrs=word&structs=&refs=%3Ddoc.id%2C%3Dsp.pohlavi&iquery=ano&sattr=sp.pohlavi&skey=rc&spos=3

Kontext: https://korpus.cz/kontext/run.cgi/sortx?q=aword%2C[word%3D%22%28%3Fi%29ano%22]&q=f&corpname=oral2008&attrs=word&ctxattrs=word&structs=doc%2Csp&refs=%3Ddoc.id%2C%3Dsp.pohlavi&iquery=ano&sattr=sp.pohlavi&skey=rc&spos=3

Both screens look the same, the concordances are in the same order. But: when you use the "Collocation is sorted: Jump to:" feature and jump to "Z", NoSkE seems to work correctly as it takes you to the beginning of Z's, while kontext will show you a screen where one Z is in the middle of M's!

However, the difference seems to be caused by the way "Jump to" is implemented, because the ordering of concordances in both interfaces is the same (at least I didn't notice any difference) and by browsing through the pages you can see one more such "missorted" Z.

Can you please track down the problem and confirm whether this issue is caused by Manatee?

NB: when applying the same procedure on non-shuffled concordances, the output of sort is OK.

1. in config.xml, it should be possible to add 0..n keywords (or "tags") to any corpus
2. corpora archive should be able to filter corpora list using these keywords

This may replace tree-like structure in the corpus selection widget.

how to replicate:

1. select a parallel corpus with 2 more languages
2. search something
3. export result to Excel or CSV
   => first language is OK, third too but second one is replaced by third one

There should be a 2-level solution:

1st level: fast access with short TTL (shorter for anonymous users)
2st level: slow(er) access with infinite TTL (probably sqlite3-based)

1. in config.xml, it should be possible to add 0..n keywords (or "tags") to any corpus
2. corpora archive should be able to filter corpora list using these keywords

This may replace tree-like structure in the corpus selection widget.

... as it is used no more

What should be checked:

1. XML validity
2. references (i.e. a string value referring to an element with specific attribute)
3. basic plug-ins configuration (especially whether there are required modules present)
4. paths - whether they exist and whether the web server has proper access rights

how to replicate:

1. use two or more aligned corpora
2. search something
3. click View->Alignment

See the title.

... instead of paginated result

1. user sessions in db (incl. individual user's session)
2. concordance cache (also individual corpora)
3. tags cache
4. freqs cache

plus it looks slightly different

... and the full query should be visible on mouseover or something like that

... and the full query should be visible on mouseover or something like that

The original Bonito code does not count with two different paginators per page which is the case of the mentioned actions where "concordance" and "current page" paginations are always present.

... and the full query should be visible on mouseover or something like that

Currently, only initial TTL distincts between short and long persistence which may (and it already does) easily confuse archivation script. In other words - there is no clear sign of when a conc. persistence record should be archived.

The format must be able to allow reconstructing of a specific sub-corpus.

Manatee cache takes up too much space now, a query that matches every corpus position (e.g. "[]") in SYN needs more than 50 GB that are stored there uless the cache is explicitly deleted.

It would be desirable to evaluate the usefulness of caching in general, and especially in cases when the concordance size is extremely large. It should be possible to come up with a better solution then, or we could also consider turning the caching off altogether. For the time being, more disk space will be reserved for the cache.

... to be able to run the command again automatically

how to replicate:

1. set corpus syn2000, search something, select you want to see attribute "opus"
2. set corpus syn, search something => error is shown

to match current bonito-open