Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: error (idunn.apache.osuosl.org: domain mac.com from 193.229.0.41
 cause and error)
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <1158829832.5384.22.camel@localhost>
References: <8164971.1158760822766.JavaMail.jira@brutus>
 <2E8FF5A4-7DB9-456B-BB7D-5DC09B83B330@mac.com> <45116160.9060605@apache.org>
 <1158829832.5384.22.camel@localhost>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B361CD45-BC03-4E25-BE0B-BD280F1BFAFB@mac.com>
Content-Transfer-Encoding: 7bit
From: Sjur Moshagen <sjurnm@mac.com>
Subject: Re: [jira] Commented: (FOR-934) i18n language override menu
Date: Thu, 21 Sep 2006 23:11:27 +0300
To: dev@forrest.apache.org

Den 21. sep. 2006 kl. 12.10 skrev Thorsten Scherler:

>> I've not been following the i18n discussions, but I have to admit  
>> that
>> when I saw Thorstens comments I wondered "why not core?".
>>
>> I'm not doing the work on this so do it however you like. But if you
>> want my (possibly uninformed) opinion then I'd say core is the  
>> right place.
>>
>
> Hmm, after all the feature contains a dispatcher contract. Further who
> said core cannot be in a plugin?
>
> I think we should split the *whole* core into plugins, that will  
> help to
> refactor and simplify the code. Now we have spread the e.g. i18n code
> all over our core. Ugly for understanding, ugly to maintain.
>
> We already agreed that we would need a skin plugin as well, which  
> is as
> well a core feature, or?
>
> IMO *everything* should go into plugins and the core would be just a
> couple of sitemaps. Maybe we should restructure the locations for
> plugins:
> tree $FORREST_HOME/plugins
> .
> |-- core
> |-- incubator (the plugins from the whiteboard)
> `-- optional
>
>
> Starting an i18n plugin and move all code to there has much more
> benefits (keeping documentation and code releated to i18n in one  
> place)
> and this is why we introduced plugins in the first place, or?
>
> So I am -1 to put it in the core, as long someone names a *good*  
> reason
> to put it in core?

One good reason could be that i18n processing cuts across all other  
processing - irrespective of which plugins you employ, i18n should  
work. i18n configuration and support should be centralised and  
available to all plugins. Perhaps a plugin could do this job, but the  
present i18n sitemap does not work with the dispatcher (I haven't  
tried with a non-dispatcher setting), and duplicates some of the i18n  
configuration in the main sitemap. Which kind of proves my point -  
decoupling i18n processing from the core (sitemap) does not seem like  
a good idea to me.

Another reason is to ensure proper and systematic support for i18n in  
all places. Forrest has been a bit patchy when it comes to i18n  
support, and still is. This makes for a bad user experiense, both for  
an advanced user developing web solutions with Forrest, and for end  
users of that web solution. When you need i18n support, you want it  
to work everywhere, with all plugins and all your documents, in all  
running environments.

The bug I reported earlier today is an illustration of my point.

After some consideration, I would actually say that if any feature  
should stay in the core and not be made a plugin, it is i18n support.

As I see it, the problems with i18n support in Forrest is symptomatic  
of its origin: it was added more as an afterthought, and not as a  
feature built-in from the very beginning. I believe the way to fix it  
is *not* to remove it from the core, rather the contrary.

Just my few cents.

Best regards,
Sjur