The problem with this (dynapi) situation and your example is that in the
DynAPI not ALL code is browser independend, in your example all text would
be different for every language.
"..but it's important to see all the versions together in order to be sure
that any change is done simultaneoulsy"
yes.
"split the files and let the german version be done by a native german
speaking (if available)"
I think when you'r doing cross-browser dhtml you should already be aware of
what browsers can do, so I don't think this applies. If you don't know the
capabilities of both browsers you will get the differences in the
implementation, something we don't want because we're creating a
cross-browser api that should work on all browser in the same way with the
same functionality.
Pascal Bestebroer
[EMAIL PROTECTED]
http://www.oibv.com
-----Oorspronkelijk bericht-----
Van: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Namens Stephan Reindl
Verzonden: maandag 11 december 2000 15:53
Aan: [EMAIL PROTECTED]
Onderwerp: AW: [Dynapi-Dev] DynAPI build, Splitting files
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
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
