Force default locale #80

Merged
merged 2 commits into from Apr 8, 2013

Conversation

Projects
None yet
2 participants
@ljader
Contributor

ljader commented Apr 7, 2013

Hi,

I've added possibility to force whole gitblit instance locale. Not everyone wants viewing Gitblit service in their native locale - english language is sometimes less verbose and more clear.

Idea: next step could be selecting locale based on user personal settings - what do you think?

Regards

@gitblit gitblit merged commit a770f32 into gitblit:master Apr 8, 2013

@gitblit

This comment has been minimized.

Show comment
Hide comment
@gitblit

gitblit Apr 8, 2013

Owner

Hi Lukasz,

There has been an outstanding request for translation selection/preference (issue 108). One reason I have not worked on it is I do not yet have a preference persistence solution.

The natural place to put that would be the UserService. I have not decided if it would be better to persist preferences in users.conf (any preference change would rewrite all users - could be a performance problem) or if preferences should be stored separately. If they are stored separately then I would consider using something like HSQLDB or more likely H2 to be able to discretely query and update a user's settings.

While undecided, if I implemented it today I would use H2 and a light-weight ORM layer to make persistence and retrieval cleaner. Naturally, my first choice for the ORM-ish layer is iciql, one of my other projects.

If you are interested in tackling user translation selection, I think we first need a generic preference store and the translation selection can be the first preference implemented.

Owner

gitblit commented Apr 8, 2013

Hi Lukasz,

There has been an outstanding request for translation selection/preference (issue 108). One reason I have not worked on it is I do not yet have a preference persistence solution.

The natural place to put that would be the UserService. I have not decided if it would be better to persist preferences in users.conf (any preference change would rewrite all users - could be a performance problem) or if preferences should be stored separately. If they are stored separately then I would consider using something like HSQLDB or more likely H2 to be able to discretely query and update a user's settings.

While undecided, if I implemented it today I would use H2 and a light-weight ORM layer to make persistence and retrieval cleaner. Naturally, my first choice for the ORM-ish layer is iciql, one of my other projects.

If you are interested in tackling user translation selection, I think we first need a generic preference store and the translation selection can be the first preference implemented.

gitblit added a commit that referenced this pull request Jul 3, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment