Routing discussion / temporary documentation

[Phaqui]

Routing (in front-end terminology) is how the app determines which page to show for which url.

Per now, the format of the url is "/ui_lang/target_lang/tool/tool_args...", where

• ui_lang is the 3-character length language code of the user interface, where the page should support five.
• target_lang is the 3-character length language code of which language the tool works for. In total around 50 such exists.
• tool is the name of the language tool. There are some 6-9 such different tools, of course also depending on target_lang.
• tool_args would be any additional arguments to the tool, such as the text which is being input, as well as any additional paramters, if any.

For example:

• /nob/sme/analyze/ shows the analysis tool, analyzing northern sami, but with the user interface in norwegian.

Is this routing scheme sufficient for the application?

implementation details

This project is a pure svelte app (not sveltekit), so we must implement routing. What we have, are custom stores for each of the variables, which when they are written to individually, the page (and url) will be reflected. As such, the current implementation does not use <a> tags to link between pages, though that should probably be implemented.

Pages should be svelte components (.svelte files), living in a "routes" folder.

[snomos]

Is this routing scheme sufficient for the application?

I guess this is pretty complete as to what we have now (others would have to check the completeness). But I would argue that going forward, ui_lang should not be a part of the routing scheme. User interface localisation is a different dimension to the app, and the routing scheme (in effect, the API) should only deal with actual functionality.

That would give a scheme like the following:

/target_lang/tool/tool_args...

This is again pretty close to the divvun API, as described here. The scheme of that (REST) API is:

/{function}/{languageCode}

Ie the order of the arguments are reversed, and tool_args... are given as DATA in a POST. I would suggest we try to make the revised version as close to the Divvun API as possible, with the future aim of merging the two into one common API REST/GraphQL server for all our services.

[Phaqui]

Sounds good on the first point. As a note on terminology, I renamed ui_lang to locale. In general it's more precise.

The user flow mimics the current page at https://giellatekno.uit.no/, where you first find the language (after optionally selecting a different locale first), then you're presented with a list of the available tools, and you select the one you want. As I understood it, that's the preferred flow of the page, since not all tools are available for all languages. The URL format of the web page therefore falls naturally from that.

Can you clarify the future aim of "merging the two"? Is the goal to have just one "service" that can respond with both the web page, and also the raw data, for example by looking at the Accept header? (As in: Accept: text/html, which a browser would send, would give you a web site, and Accept: application/json would give you data back).