Fossil

View Ticket
Login

View Ticket

2023-01-17
15:27 Closed ticket [91683f49]: Mechanism for i18n the product UI plus 3 other changes ... (artifact: ef9beaba user: stephan)
2011-09-08
22:15 Closed ticket [8d786b9a]: Should be ability to translate into Russian(other languages) plus 2 other changes ... (artifact: f65963ee user: dmitry)
2010-02-19
12:29 Ticket [91683f49] Mechanism for i18n the product UI status still Open with 1 other change ... (artifact: 79833834 user: anonymous)
2010-02-10
11:06 Ticket [91683f49]: 2 changes ... (artifact: 3548be53 user: ron)
07:06 New ticket [91683f49]. ... (artifact: 2e9b545c user: ron)

Ticket Hash: 91683f49e8c168ba8f349a1e83cc36a2b7b249c1
Title: Mechanism for i18n the product UI
Status: Closed Type: Feature_Request
Severity: Minor Priority:
Subsystem: Resolution: Wont_Fix
Last Modified: 2023-01-17 15:27:30
Version Found In:
Description:
There is no obvious mechanism by which one might localize the UI in Fossil. If I want to have Spanish-speakers (who don't know English well) use the product, I currently need to go through all the menus etc., and manually change them. This is extremely time-consuming and prone to failure.

I would like to request we use something like GNU gettext (which is very easy to use), and then whoever wants to contribute a localization may do so. Then, one only needs a way to indicate to Fossil that it should use a specific locale (for example, adding "locale=es" as query parameters).


ron added on 2010-02-10 11:06:23:
It occurs to me that it might be difficult to deploy a gettext type of solution across platforms; though if the "mo" files are deployed relative to the executable in a known manner, that's not a problem.

Another possibility might be to leverage the SQLite backend and just store the translations there; but then, we would have to engineer a reasonable way for the data to get populated, and that adds (I think) quite a bit of complexity.


anonymous added on 2010-02-19 12:29:49:
Whilst gettext is certainly a good practice towards i18n/l13n, it's certainly not the be-all and end-all of dealing with multiple languages. I'd be in favour of the languages being done at compile time, not inside the repository as much as possible. Constants, templates and lots of #define are suitable work arounds.