From: Petros Evdokas <petros_cyprus-AT-burleehost.net>
Date: 07 Aug 2002 14:58:51 UTC   (01:58:51 PM in author's locale)
To: dadaIMC Support <support-AT-dadaimc.org>

Cyprus Indymedia
Expanding /Testing the language capabilities of Dada
imc
---------------------
Part 1.

Hello to Spud, and
to all our friends and colleagues working to expand the
language capabilities of Dada imc in relation to the
Cyprus Indymedia project,

Many thanks for your help and your patience with all of
the many aspects of this collaboration.
What follows is a mixed bag of commentary, updates,
thoughts and suggestions regarding the current phase of
our tests and implementations.

General reference materials for this discussion are,
this test page:
alt.baltimoreimc.org/newswire/index.php
and recent discussions archived at our Eastern
Mediterranean imc tech email group files:
lists.indymedia.org/mailman/public/eastern-mediterranean-tech/

So far, the only hellenic/greek language tests I know
for sure that can speak of, were done by copy-pasting
plain text (from ".txt" files) into the appropriate
windows provided for publishing on the "publish" page.
We will have to do some more tests, but so far what we
have is this.

1. In a recent letter about the setting up of the new
test site, Spud wrote:
"The display on my server will currently output the
text twice -- once
after running the body through htmlentities(), and once
after running
the body through htmlspecialchars(). The first one
appears to be broken
in PHP 4.2.1/2; I've submitted a bug report to
bugs.php.net. But the
htmlspecialchars() version seems to do OK."

Our tests verify this, but with one complication,
better explained in Part 2 of this letter.
Even though I dont understand the technical
implications of the difference between those two types
of text { htmlentities() versus htmlspecialchars() }, I
can say that "as is", the set which works,
htmlspecialchars() , works well for all of our needs in
the hellenic- greek language, including special and
"weird" characters (punctuation marks, etc), which
often fail on other websites. Im almost hopeful we are
close to a solution to our problems!

2. About the display of our tests: Regardless of what
kind of text was entered, the character set on the
browser is "forced" by the webpage to display "greek
iso", even for text which was entered in the "greek
windows" character set. This occurs when viewing both
through the Netscape browser, and the Microsoul
browser. When the visitor changes the setting to view
"greek windows" character set, the displays of the
second type of text {created by htmlspecialchars() },
work just as well, whereas the other ones {created by
htmlentities()}still dont work.

There is something about the character set "greek iso
8859-7", which I dont understand (its beyond my
knowledge) but my observations are as follows:

Ive been a follower of web developments in the realm
of webpages and email capacities regarding the use of
the greek- hellenic language since 1995. Not as a
professional, but as a user/ visitor. I observed this
trend: a lot of sites which require the visitor to use
"greek iso 8859-7" are usually problematic, especially
if they involve java. I dont know what it is. And I
also found that sites which specify to use "greek
windows 1253", or do not specify at all (meaning they
work for both character sets), usually are problem-
free. I dont know the significance of this, but Im
wondering if, for future evolutes of dada imc, we
create a test site with "greek windows 1253", which
might by-pass some of the problems?
* I must qualify that this is just conjecture, and that
Im not suggesting it based on anything concrete other
than repeated observations. At the level that our test
site seems to work right now, we can probably get away
with not needing to do any more adjustments. (This is
according to the ancient american dictum "if it works,
dont fix it").

3. At some point, Spud had sent me a list of phrases
which need to be translated by us, in order to complete
the localization for hellenic-greek, and also for
turkish. These are phrases which the webpage will
display in its interaction with the visitor, such as
"publish" or "preview". I will forward that list (or
the updated version of that) to our team, as soon as
possible.
For most of those it will be impossible to translate
unless we know where they occur, or what the context
is, and I think Spud is working on creating a way to
guide us on it, or something like that.

4. Some problems occured with uploading pictures (media
files) during the tests. Some commentary on those,
partly in response to querries from Spud.

- some of the language tests took place at the exactly
the same second that Spud was making some changes on
the server, and the files got garbled up. Our Netscape
browser also crashed during that event, and presented a
problem it had never shown before, ie. the browser
History file stopped writing and remained empty no
matter how many sites wed visit. (In the end we had
to recreate that file.) Perhaps some of the
instructions to the server bled through to the visiting
browser? Is this possible, or is it science fiction? .
Most likely, Spud had encountered echoes of this
particular incident when he wrote the following:
"Some browsers send the MIME-type as "open" -- I can't
figure this one
out at all. You'll notice, in the Media Gallery, the
MIME-type is
indicated next to the file size. Some of them are
marked simply
"(open)", but it wasn't my code that put it there! If
anyone knows more
about this, let me know. Otherwise, I can work around
it (and try to
detect MIME-type based on file suffix for those types),
but I don't know
what other "fake" MIME-types may crop up in the future.
So this is
"fixed" for now, but it's a workaround."

I believe we can ignore problems of that type, in terms
of seeing them as "media upload problems". But if
theres something to look into for those moments when
we need to work on the server, if theres a chance we
might harm our visitors browsers, lets have a look at
it.

- in terms of media file uploads, it seems theres a
difference between the current test site, and the
previous one we had at the bandwidthcoop server.
Perhaps the improvements in the dada imc used in new
site (is it a "higher generation"?) were enough clear
the problems? Or perhaps something about the way it had
been installed? When its time to re-install the
internationalised/ localised version onto the
bandwidthcoop server, we might need to look at that
procedure again.

- Spud had mentioned that there had been some tests by
visitors with an obscure broswer type, named "w3m". My
proposal is that we can safely rely on the domination
of the internet by the #$%^#4! imperialist browsers
made by Microsoul and Netscape, and simply make our
sites work well for visitors who use one or the other
of those two. It might appear that we ignore the users
of other browsers, but after all, the the work of
Indymedia is politics. All types of guerilla warfare,
whether cultural guerilla, armed guerilla, or internet
guerilla, are founded on the simple premise that we use
what the general population uses in everyday life, and
*accept* the contours of the landscape. Future evolutes
of Dada imc might address the needs of other browsers,
but for now, I dont mind if we appear to be elitists
by not enabling every possible browser that exists.

Part 2 of this letter will contain some more feedback
and information related to our language tests (turkish
language; more tests to do), and will have some more
comments.

Thanks so much, to all of you,
Petros
------------------------

-------------
To unsubscribe, send blank email
to dadaIMC-off-AT-lists.dadaimc.org