Skip to content
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

Make known group labels require 'default' instead of 'en' #1316

Merged
merged 1 commit into from
Jan 17, 2025

Conversation

LukasKalbertodt
Copy link
Member

This just makes it work the same as all configuration, which was changed a while ago. Both TranslatedString types were combined into one type. This commit also adjusts some docs that have been forgotten.

There is a second subtle breaking change: it's only possible to import labels with languages that Tobira knows about, and not arbitrary two- letter codes, like before. I don't expect that to be a problem. Tobira was never able to actually show these in the UI anyway.

This just makes it work the same as all configuration, which was changed
a while ago. Both `TranslatedString` types were combined into one type.
This commit also adjusts some docs that have been forgotten.

There is a second subtle breaking change: it's only possible to import
labels with languages that Tobira knows about, and not arbitrary two-
letter codes, like before. I don't expect that to be a problem. Tobira
was never able to actually show these in the UI anyway.
@LukasKalbertodt LukasKalbertodt added the changelog:nope Not worth mentioning in the changelog label Jan 16, 2025
@LukasKalbertodt LukasKalbertodt added this to the v3.0 milestone Jan 16, 2025
@github-actions github-actions bot temporarily deployed to test-deployment-pr1316 January 16, 2025 14:24 Destroyed
backend/src/api/model/acl.rs Show resolved Hide resolved
@owi92 owi92 merged commit 4eded8e into elan-ev:next Jan 17, 2025
5 checks passed
@LukasKalbertodt LukasKalbertodt deleted the translated-group-labels branch January 20, 2025 10:25
owi92 added a commit that referenced this pull request Jan 20, 2025
This is the start of some backend refactoring. We noticed for a while
that many types don't cleanly fit into one submodule like `db`, `api`,
or something else, because they have DB impls, are loaded from the DB,
are exposed in the API and potentially other uses. Having a new top
level module house these make sense to me. I also don't mind having
smaller files in there, with fewer types per file. And I also don't mind
having many submodules inside `module`.

Note that this doesn't mean that we won't have two types for the same
"thing" at all anymore. Sometimes it makes sense to have a separate
type! For example, see some `search::*` types below which represent
exactly what's stored in the search index. We want to disconnect that
from the API representation somewhat, they don't necessarily need to
match.

This PR does not perform the full refactor, far from it! It just adds
the module and moves 3 interesting types already. To reduce merge
conflicts I expect us to move things around over the next couple months.

This is based on #1316, so that should be merged before.

---

I went through all modules (except `api`) and checked all types. Here
are more things I would move in the future:

- Pretty much everything in `db::types`
- `search::{TextSearchIndex, TextAssetType, TextMatch}` probably into
some `model::text`?
- `search::{Event, Playlist, Realm, Series, User}`: not sure about that.
These are mostly a representation of whats stored in the search index
and have a separate `SearchFoo` type in `api::model`. I think these can
stay. With one exception: `search::Playlist` currently does not have a
separate `SearchPlaylist` type. It should probably get one at some
point.
- Lots/most/all things in `api::model`? I haven't really looked at it
closely yet.

---

In terms of review: ehm... all the moving around and import changing is
annoying to review and I don't really see the point. Maybe roughly look
at the new structure? And maybe test a bit? Dunno, or nothing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog:nope Not worth mentioning in the changelog
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants