Re: AW: [Dynapi-Dev] DynAPI build, Splitting files

[Jordi 'I. M. <jmi...@or...>]

As long as you are sure the german writer, the english writer and the french
writer are writing exactly the same, and there is one person telling them what
do they have to write and what do they have to tell. Otherwise, you'll end up
with a site that depending on the language you choose, the information presented
and the tone of the speech is totally different.

The issue here are not the benefits of splitting-up the files ( we all know them
) but the danger of desynchronization between browsers that comes together with
the fact that  ( regardless of our good intentions and constant discussion ) we
do not have a solid guideline, a plot and a leading man who picks up all the
people's work and decides what goes in and what is discarted due to not being
cross-browser, a leading man that you would have in the multi-language situation
you exposed.

If I was sure that having split files would only result in having split files
and not split functionalities, I'd join the "split" cause, but seeing the APIs
evolution in the last year, I don't think we'd make it.

If I write 'would' one more time, I'll go nuts.

Stephan Reindl wrote:

> Oh come on. If you're supposed to write an international site for visitors
> in 5 languages, would you really consider writing (and editing) all the
> different texts, labels, figure captions, etc in ONE file only and
> separating the languages by deeply nested if`s ?
> Would you say, ok, I don't know german so well, but it's important to see
> all the versions together in order to be sure that any change is done
> simultaneoulsy. I try to learn german (and french and kisuaheli, etc.)
> Or would you prefer to define the "look & feel" of the site, split the files
> and let the german version be done by a native german speaking (if
> available)?
>
> Stephan
>
> >
> > What advantage would you gain by splitting up your example?  Speed
> > wise, that is not the reason for loading taking a long time.  The
> > speed problems are due to DynLayer creation.  If you haven't seen yet,
> > Dan is creating a new inline dynlayer creation system that will speed
> > up this process.  While splitting up the core files may seem nice, it
> > offers no real advantage.  Especially with the new jspack files, the
> > file sizes are going to be small anyways.
> >
> > --
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev