From: dadaIMC Support <support-AT-dadaimc.org>
Date: 07 Aug 2002 19:13:40 UTC   (11:13:40 AM in author's locale)
To: "dadaIMC Discussion" <dadaIMC-AT-lists.dadaimc.org>

Petros et al --

Concerning the alt.baltimoreimc.org site: The number 1 important thing is that right now the alt.baltimoreimc.org server is unreachable. My ISP is working on the problem on their end (their whole connection is down). Funny timing, given your message, and the fact that I'd just prepared an announcement/request for translators to send to the IMC-tech and
IMC-translation lists...BLECH! I hope it comes back up soon (it's been down for 9 hours, and it's also the server that hosts the Baltimore
IMC...)

To address (and make) some points:

1) The use of ISO-8859-7 for the Greek character set was based on its
specification as the default character set of the el_GR locale on
standard Linux installations. When "Hellenic" is selected as the display language, I set the charset of the page to iso-8859-7 as you've noticed, but you can tell your browser to force display in Greek Windows 1253 if you want.

However, the article input form also specifies that it will ACCEPT input in iso-8859-7, but does not specify Greek Windows 1253. (It will also
accept Unicode UTF-8 for any language). I suspect that we haven't run
into any problems because we haven't used any of the characters that
differ between the two character sets. I found an informative page at

www.cs.tut.fi/~jkorpela/unicode/greek.html

about the differences between iso-8859-7 and Greek Windows 1253. Nice
little reference for anyone developing sites in Greek. If someone wants to attempt tests that involve some of the "problem characters" (esp.
GREEK CAPITAL LETTER ALPHA WITH TONOS), we could discover more about it.

In the end, I'm willing to make whatever changes will fit your needs the best. You will (at least for now) be the primary users of Greek in
dadaIMC, so whichever character set solves your problems is good for me.

2) Yes, the code at alt.baltimoreimc.org is considerably more advanced than the code at bandwidthcoop. The bandwidthcoop codebase has no
internationalization support, and there have been a number of bug fixes and enhancements aside from that (addressing things like MIME-type, your image upload problems, etc). The code at alt.baltimoreimc.org is the
basis of the next release, which will be available as soon as I have
some of the translated files for other languages.

3) Anyone interested in translating the English language template file into any other language should see
www.dadaimc.org/dev/index.php. The latest version of
the file to be translated is available there, as well as a quick form to fill out so I can keep track of translators.

The new version of the template file (called a "POT file" for Portable Object Template) includes comments for EVERY string, indicating on what pages it can be found on the site, and with notes on context and
meaning, so you should have enough information to correctly translate
entries.

More information, including guidelines and tips, is available in the
/dev/ section of the dadaIMC site noted above.

4) I'd still like to track down the source of the "open" MIME-type (at least figure out what browser is sending it), but it's fair to say that I've worked around the problem for the time being. As for the w3m
text-based browser, I can say that a) it's broken, and incorrectly sends the wrong MIME-type for media uploads, and b) trying to work around that problem should probably not prevent the release of the next dadaIMC
version.

Getting ready for the next big release...
Cheers,
spud.

On Wednesday, August 7, 2002, at 06:58 AM, Petros Evdokas wrote:

>
> 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
>
>
-------------------------------------------------------------------
a.h.s. boy
spud(at)nothingness.org "as yes is to if,love is to yes"
www.nothingness.org/
-------------------------------------------------------------------

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