Opened 10 years ago
Last modified 7 years ago
#1946 reopened defect
Make languages.yml translatable
Reported by: | avar | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | website | Version: | |
Keywords: | Cc: | StefanB |
Description
Currently the languages table (read from config/languages.yml) only has entries for language code, english name and native name.
--------------+------------------------+----------- code | character varying(255) | not null english_name | character varying(255) | not null native_name | character varying(255) |
It should be possible to translate this table into arbitrary native languages, so that when reading the diaries one sees "{{language_name}} ({{native_name}})" instead of "{{english_name}} ({{native_name}})". Where language_name is the name of the language in the locale the current user is using.
This would require changing languges.yml like so:
de: - english: German - native: Deutsch + en: German + de: Deutsch + is: Þýska
And changing the languages table to something like:
--------------+------------------------+----------- code | character varying(255) | not null code_to | character varying(255) | not null name | character varying(255) |
Attachments (1)
Change History (11)
comment:1 Changed 10 years ago by
comment:2 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
(In [15900]) Added localized language names with plugin from http://github.com/grosser/i18n_data/tree/master (fixes #1946) Diary entries in same language linked (lists and rss)
comment:3 Changed 10 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Thank you for making the trunk undeployable - please do not make major changes like adding new plugins without consulting first.
For the record the situation with languages.yml was a result of a deliberate decision made at the hack day. In hindsight that decision needs reviewing I agree but it needs more thought than has gone on here to decide on the best solution so please leave this open until I am back from holiday.
comment:5 Changed 10 years ago by
I thought announcing it here and seeing no objections meant that the plugin was acceptable.
Just of curiosity, why was it undeployable? Was it technically broken in some way, or just socially not agreed enough upon? Don't want to make the same mistake again.
Can I redo other changes that are not requiring the plugin?
No rush though, enjoy your holidays!
comment:6 Changed 10 years ago by
Cc: | StefanB added |
---|
comment:7 Changed 10 years ago by
As the admin of the server is on holiday he hasn't had time to check the plugin to see if it is suitable, and doesn't have any bad side effects or if there are better alternatives.
Less than 24 hours is rarely enough time during a normal working week to review a big change in the code, never mind when the main sys admin is on holiday.
At the moment we are only accepting small bug fixes into trunk. Generally major changes are done in a branch so that trunk is always deployable. Even if the branch only lasts a few days or weeks, it still means that trunk can always be deployed if there are any urgent bugs that need to be fixed, or there are other code changes that can be deployed straight away.
comment:8 Changed 10 years ago by
Changed 10 years ago by
Attachment: | i18n_data-plugin.patch.gz added |
---|
adding i18n_data plugin with example use for consideration
comment:9 Changed 10 years ago by
comment:10 Changed 7 years ago by
Owner: | changed from Tom Hughes to rails-dev@… |
---|
How about using ready-made data in a RoR plugn, such as: http://github.com/grosser/i18n_data/tree/master ?
There are several other, similar plugins.