Regarding localization

[jjgancfer]

Should we localize the application? Since we have hardly started, I think it is an optional requirement we should consider now. I have looked into it and there seem to be many React localization modules.

[GOLASOOO]

I agree with your idea to include localization in the proyect but I believe we should first focus on learning about wikidata and see if it is feasible to implement localization in the question generator module. I am concerned about those questions whose entries in wikidata may be wrong or incomplete, depending on language.
However, I think it would be a great feature to implement if possible.

[jjgancfer]

According to Wikidata's SPARQL query service documentation, both a language and a fallback language can be specified in the query. If we can't use SPARQL, then I suppose we could have two options: through REST calls or failing that, building a service exclusive to that. Regarding the latter, I suppose Wikidata-Toolkit is worth looking into, although this link shows it does not support the Wikidata Query Service.

[GOLASOOO]

As SPARQL now seems to be a possible alternative, I think we should discuss which is the best approach. On my opinion, building our own service should be the last option as there are other more important things to pay attention on.
However, I am unsure regarding on whether to use SPARQL or REST. SPARQL seems to be compatible to Spring boot via Apache Jena and REST should be easily configured too.
I am planning on learning about SPARQL queries and how to implement it to Spring boot today. I will keep you updated.

[gony02]

From my point of view, localization seems like an interesting extension for the project. However, I think we should avoid doing the optional exercises until you have the system working.

[sergioqfeg1]

I think it's an interesting idea to be considered, but since we haven't really started to work, we should first focus on other things.

[GOLASOOO]

This is a bit long as an answer but I tried to simplify and make as clear as possible.
I have been researching a bit on the different approaches we can choose in order to query from Wikidata.

Spring Boot:

This is some info about most of the libraries:

They are plenty and all of them seem to use REST to query the data from wikidata's endpoint. Also, as far as I am concerned, all of them use JDBC for querying. However, due to volume I have not check on every one.

Pros (for most of the libraries):

• Many file formats available (json, csv, xml,...)
• Well documented
• Allow parameterized queries

Cons:

• A minute of processing time is granted per minute and per IP and 30 error queries per minute

If using Jena, which seems to be the most important library out there regarding SPARQL:

First, it also uses REST so the previous point will be likely to be applied here too. It provides a library to connect to Jena SPARQL API which has lots of different capabilities.

Pros:

• It has a RDF (format which can be queried via SPARQL) mapper which is based on JPA so they both look alike.
• It provides an endpoint called sparqlify which is a rewritter from SPARQL to SQL. Its main features are:
  • Supports JPA
  • It is available on PostgreSQL
  • It can be set so it automically simplifies queries for better performance
• Adds another possible syntax for querying, which seems optional and well documented. However, I have not researched enough enough about it (I will do if you guys think it is an interesting option). It is based on algebra.
  + Allows query transformations
  + Provides code for implementing our own SPARQL endpoint

Node.js

Regarding Node.js, there are few libraries available which have not been updated in some years. It is way simpler as it is basically an HTTP request in js.

[Toto-hitori]

When adding localization to the API we should take this into account:
https://simplelocalize.io/blog/posts/spring-boot-simple-internationalization/

[jjgancfer]

When adding localization to the API we should take this into account: https://simplelocalize.io/blog/posts/spring-boot-simple-internationalization/

I don't think the API (the schema of the data returned) should be localized, it would create problems when receiving the data that would need to be solved. I do think the results returned should be localized, though.

Edit: edit due to misunderstanding

[jjgancfer]

In the feat/webapp/top-bar branch I've just localized using react-i18next, and the result as been fairly easy to obtain. The module automatically loads a translation.json file located within the public/locales/{lang_code} directory, so that is really all we have to add. I will be adding some tests, so I don't expect to PR until a few at the very least, but the code is already uploaded and working if anyone wants to check it.

Edit: the mentioned branch is waiting for review in #32.

[jjgancfer]

Since no one seems to be commenting on this right, I'll give an update. We seem to be doing somewhat alright with the localization, but we have left mocking the useTranslation() hook. The tests do currently work, but they produce warnings on this matter.

[jjgancfer]

The fix for the warning of the tests has been merged in #126.

[jjgancfer]

It seems we currently have nothing left to discuss, so we may as well close this issue.