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
