[kdewebdev-site] Localisation

[David Joham]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 28 April 2004 07:09 pm, jacob coby wrote:

>
> Pretty much anything that uses fstat/stat/lstat is
> cached in PHP.  The first call can be expensive, but
> the subsequent calls are basically free.
>

That's cool

> Thinking that there will be 50-100 localized "words"
> per page seems to be underestimating by a long shot.
>

mea culpa. I meant "phrases" 50-100 is what typically goes into a LaserJet 
page.

> I think that whatever localization technique we use
> should generate ONE localized file per page, not per
> phrase or word.
>

Please expand on this idea. How would you accomplish this?

> I think that the default language (english, I'm
> assuming) should be built in, and not require any
> additional I/O.
>
> A generated php page would do something like:
>
> ---
> // setup the default dictionary
> $__dict[0] = 'blah blah';
> $__dict[1] = 'another word';
> $__dict[ ...;
>
> // handle localization
> figure_out_the_language();
> if(file_exists("lang/$thisfile/$lang.php"))
>   include("lang/$thisfile/$lang.php");
> else
>   $lang = "en-US";
>
> // the $lang.php file from above would generate an
> // array to overwrite/fill the $__dict[] array above
>
> // display something
> print "<li>".$__dict[0]."</li>\n";
> print "<li>".$__dict[1]."</li>\n";
> print "...;
>
> ---
>

You would have one lang.php for each page? Is that how you would get your one 
localized file per page? Am I reading this right?

I like everything about this except for the dict[<integer>] part. I assume 
there is a way we could replace <integer> with 
<some_user_friendly_constant_that_represents_the_integer>? :)

> It would require some additional memory, yes.  

memory is cheap - well, at least it used to be....

> And it 
> would require a little longer to parse per page, yes.
> However, I think in the long run, it would generate a
> more resilient and more scaleable site assuming:
>
> 1. English is the default language
> 2. Most will read the site in english
> 3. The time it takes to do a file_exists() and
> include() is greater than the time it takes to parse
> the english part of the original file.
> 4. The time it takes to include and parse a file is
> acceptable.
> 5. Content developers are lazy.  They want to see
> something with the minimum of fuss.

Hey! I resemble that remark...

> 6. Translators are lazy.  They want to see that they
> string they just translated works with the minimum of
> fuss and/or missing content.  They want to be able to
> translate one or two phrases when they have time, not
> an entire page.
> 7. Developer turn-around.  OSS projects generally
> don't keep programmers for very long.  You'll get a
> handfull of patches to fix some bug or scratch an
> itch, and then they're gone.  K.I.S.S.
>
>
> Anyways, I thought I'd throw some more thoughts out
> there, and hopefully we can get _something_ done.
>

Jacob, I like this a lot. I would recommend that you get together with 
DReddish and see if you can combine proposals. They seem very similar and I 
like where you're both going. I would very much like to see a very simple 
working PHP example mailed to this list with these ideas put into code.

Chris, you're still in the running and I *will* fully consider your proposal, 
but I have to admit I'm really liking how Jacob's and DReddish's proposal is 
turning out primarily due to my perception that reasons #5 and #6 above are 
better suited by their design. 

Are there any other opinions out there?


David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAkGyVdGtRHnP4AioRAsVIAKC2Z/GYsFyM/JLl3MKdtm8qGQnj5wCfWFMB
mqSxOtsMb12oFSppGM8+m0s=
=2D5B
-----END PGP SIGNATURE-----