ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

[Proposal] - How should we handle i18n?

Added by Eric Davis at 2011-02-11 01:27 am

[Liquid Syntax Error] Variable '{{' was not properly terminated with regexp: /\}\}/
Right now we are requiring a specific version of the i18n gem (0.4.2). I've seen this cause some problems, especially during deployments. # it requires Rubygems which might not be used in all environments (e.g. Debian) # other working versions of i18n will not be loaded (e.g. 0.4.1, 0.4.0, 0.3.7) # depreciated syntax warnings for locales using the @{{@ syntax (which includes most plugins) I've seen a few discussions about how to "fix" this but I wanted to get everyone's thoughts on it. Maybe flex the requirement to only be @gem < 5.0@ or even bundle a working version of the gem? Eric Davis

Replies (7)

RE: How should we handle i18n? - Added by Felix Schäfer at 2011-02-11 08:40 am

I'd say bundle 0.4.2 (unless it's known there is something bad in there), switch the syntax to the %{} format (if the gem is bundled, no problem), change the deprecation warning to not fire every time it encounters @ format and deprecate the @ format for plugins in chiliproject 2.0.

RE: How should we handle i18n? - Added by Eric Davis at 2011-02-11 07:34 pm

Felix Schäfer wrote:

deprecate the @@ format for plugins in chiliproject 2.0.

How about deprecating now (1.x releases)? Plugins are already throwing a ton of messages in both Redmine and ChiliProject and if we deprecate now then we can remove it in 2.x which will let us upgrade to Rails 2.3.latest (or maybe even Rails 3).

Eric Davis

RE: How should we handle i18n? - Added by Holger Just at 2011-02-11 07:51 pm

I'd say we deprecate it for Bell and remove it for 2.0. We should see to let all that cruft go and smooth transition towards Rails 2.3.11.

RE: How should we handle i18n? - Added by Felix Schäfer at 2011-02-11 08:14 pm

Eric Davis wrote:

How about deprecating now (1.x releases)?

Well, I thought I was being aggressive on the schedule already, but the earlier the better :-)

RE: How should we handle i18n? - Added by Eric Davis at 2011-02-11 11:55 pm

Felix:

Yea, if we deprecate in 2.0 then we can't remove it until 3.0 (around February 2012!).

Eric Davis

RE: How should we handle i18n? - Added by Felix Schäfer at 2011-02-12 12:01 am

Eric Davis wrote:

Yea, if we deprecate in 2.0 then we can't remove it until 3.0 (around February 2012!).

Hadn't thought of it that way.

Do you want to deprecate them for 1.1.0 already? If so, could you make the corresponding tickets? I'd be willing to take care of converting the existing language files.

RE: How should we handle i18n? - Added by Eric Davis at 2011-02-14 01:26 am

I think 1.1.0 is already on a tight schedule. Maybe we should set aside some time to put in some depreciations into a later release, like how Rails did for the 2.3 branch once 3.0's API was standardized. (say 1.3.0 (random later release)).

Eric Davis

(1-7/7)