-
-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extract language tags from FLEx projects and store in DB metadata #952
Conversation
Doesn't store anything in the DB yet.
We skip pronunciation since it's a subset of vernacular and we don't need it. We load all vern/analysis, and current vern/analysis.
This can go in another PR
Migration will be in the next commit.
VernacularAndAnalysisLangTags now returns two lists of FLExWsId objects with the IsActive properties set, rather than four arrays of strings.
Actually, now that I take another look at #922 this doesn't yet do everything the issue asks for. For example, there's no GraphQL filtering available yet. Marking as draft and removing review request for now. |
UI unit Tests11 tests 11 ✅ 0s ⏱️ Results for commit 388e474. ♻️ This comment has been updated with latest results. |
While we're adding hg runner commands, we can easily add one to extract the GUID from the LangProject element, which may allow identifying projects which started out as copies of each other even though their Mercurial repo histories have no common commits.
Also include a DB migration and GQL schema update
Since we're using `\K`, a rarely-used feature, we should explain it.
The XML element is named VernWss, not VernVss.
The order in which FLEx returns writing systems is current first, then all non-current (if any) at the end. We want what we store in the project metadata to match that ordering.
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.
Self-review finished. Marked a few places I'd like specific feedback on: e.g,, should I spend the time to do the proposed refactor, or is it readable enough already and I should move on to something else?
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.
just some minor requests, including removing an empty migration
backend/LexData/Migrations/20240715044054_AddIsDefaultFieldToFLExWsId.cs
Outdated
Show resolved
Hide resolved
frontend/src/routes/(authenticated)/project/[project_code]/+page.svelte
Outdated
Show resolved
Hide resolved
frontend/src/routes/(authenticated)/project/[project_code]/+page.svelte
Outdated
Show resolved
Hide resolved
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.
looks good to me
Eventually these tests should clean up after themselves, or use randomly-assigned project codes so that they don't conflict. But for now this is good enough for a quick fix.
Fixes #922.
This PR extracts language tags from FLEx projects, but does nothing yet to validate or process them. That might come in a separate PR; this one just stores the language tag data into a JSON column and leaves the analysis for later.