languages: interface, server implementation #105
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems good for me
Rebased |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code lgtm, although once something is shown I would find it a little awkward to have a hardcoded list of languages.
(needs a rebuild)
src/server-entry.ts
Outdated
new EntityInitializer(), | ||
), | ||
); | ||
const languageRepo = new WikibaseContentLanguagesRepo( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had we continued doing this outside the export, all requests would have a shared the same language API response. This could be, carefully crafted, a performance optimization in the future but should be an active decision. (Not currently possible for this scenario with the API response containing request-specific content [translation] but the deferred member always resolving to the same value once it is known)
Rebased |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm in general!
tests/unit/server/data-access/WikibaseContentLanguagesRepo.spec.ts
Outdated
Show resolved
Hide resolved
@@ -14,7 +14,8 @@ | |||
"quotemark": [true, "single"], | |||
"interface-name": false, | |||
"ordered-imports": false, | |||
"object-literal-sort-keys": false | |||
"object-literal-sort-keys": false, | |||
"import-spacing": false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The long class names, combined with the max-line limit made this necessary.
Unfortunately import-spacing
is not configurable any more than on/off, so it is unclear how iffy it allows the header to looks, but I still perceived it as the lesser evil to allowing very long lines everywhere or plastering all uses with config comments.
If someone has a better idea I'd be happy to change that.
Updated to address @jakobw's valid concerns. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gave it another look. I like that the evilness is now confined in WaitingForLanguageWikibaseContentLanguagesRepo
.
Add the LANGUAGE_UPDATE mutation and use it with dummy data from the LANGUAGE_INIT action Bug: T210407
Implements the LanguageRepository interface for the server side, sharing an API response with the implementation of LanguageTranslationRepository which happens to contain all the necessary information (and some additional in user language). Bug: T209288
Use https://www.npmjs.com/package/rtl-detect to determine language script directionality. Bug: T209288
Rebased |
For the client with uls. Bug: T210406
Provide languages and their directionality to the application.
Use this as base to set languages in the client.
Bug: T210407