question: why are user languages stored in settings table? #951

Closed
opened 2026-02-04 23:08:44 +03:00 by OVERLORD · 2 comments
Owner

Originally created by @ezzra on GitHub (Dec 11, 2018).

I am confused, that the user specific languages are stored in the settings table like:

user:11:language | en
user:12:language | de

I would expect to find this in the users table, is there a specific reasons for this? I am just checking out to work on #1152 and I would have stored the specific homepage data for roles in the roles table, but now I am unsure if I should follow this style?

Originally created by @ezzra on GitHub (Dec 11, 2018). I am confused, that the user specific languages are stored in the settings table like: ``` user:11:language | en user:12:language | de ``` I would expect to find this in the users table, is there a specific reasons for this? I am just checking out to work on #1152 and I would have stored the specific homepage data for roles in the roles table, but now I am unsure if I should follow this style?
OVERLORD added the Question label 2026-02-04 23:08:44 +03:00
Author
Owner

@ssddanbrown commented on GitHub (Dec 12, 2018):

This method of storage just provides a flexible way to store any user (& system) preferences really. The language could have been stored on the users table but it's not really queried or used much, Just in a single core place really. If it was used more, to the point language was shown in multiple views or if it needed to be searched upon then it might be worth moving it out otherwise the Settings system provides a nice abstraction where we can implement caching for example or additional logic (Storing guest data in the session for example).

If you're looking to implement something for #1152 I'd suggest maybe setting out a feature proposal before potentially wasting time building without a level of certainty that what you'd build would be implemented. The use-case on that issue is fairly specific.

@ssddanbrown commented on GitHub (Dec 12, 2018): This method of storage just provides a flexible way to store any user (& system) preferences really. The language could have been stored on the `users` table but it's not really queried or used much, Just in a single core place really. If it was used more, to the point language was shown in multiple views or if it needed to be searched upon then it might be worth moving it out otherwise the Settings system provides a nice abstraction where we can implement caching for example or additional logic (Storing guest data in the session for example). If you're looking to implement something for #1152 I'd suggest maybe setting out a feature proposal before potentially wasting time building without a level of certainty that what you'd build would be implemented. The use-case on that issue is fairly specific.
Author
Owner

@ezzra commented on GitHub (Dec 12, 2018):

maybe setting out a feature proposal before potentially wasting time

I am planning to do this, but before I wanted to check out the current code structure :) And anyway, thats a feature our team needs so I will have to build it in the next days.

@ezzra commented on GitHub (Dec 12, 2018): > maybe setting out a feature proposal before potentially wasting time I am planning to do this, but before I wanted to check out the current code structure :) And anyway, thats a feature our team needs so I will have to build it in the next days.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#951