On Nov 29, 2004, at 7:17 AM, Ben Collins-Sussman wrote:
> On Nov 28, 2004, at 9:51 PM, gar wrote:
>> Today I make the pitch to the manager that we migrate to Subversion
>> (tortoiseSVN client) to handle VC and XML as our data format. This
>> will work fine for English, but we also need Arabic support. I can
>> handle translating the UI strings, but currently Subversion doesn't
>> seem to like log messages in Arabic. I haven't tried using Arabic
>> for properties yet.
> I'm not sure what problems you're having: Subversion stores all log
> messages and filenames as UTF8 in the repository. Subversion is
> already "internationalized" to this degree -- you can use any language
> or encoding you want for files and log messages. Just set your
> client's locale to something that iconv can use to convert back and
> forth between 'native' locale (some Arabic encoding system) and UTF8.
> It's that simple.
Wow, that's what I call a fast response. Thanks!
I'll post later today (Doha time) more detailed info on the response I
got when I tried to use Arabic log messages. Now that I think of it
I'm not sure if it was the server or client that had the problem.
> At the moment, there's also a localization effort going on for several
> languages, so that all errors and text printed to the user are
> translated by gettext(). Nobody's done an Arabic translation yet, but
> volunteers are certainly welcome.
>> So my question is, can somebody familiar with the code give a rough
>> estimate of the number of programmer hours it would take to provide
>> Arabic support? It is possible I'll be able to get some (modest)
>> funding, so if you're interested and available please let me know.
>> No promises though at this point; I just think there's a very good
>> business case that funding open-source Arabization of subversion and
>> tortoiseSVN is the best way to solve our version control problems.
>> This is something we would need relatively quickly, in the next few
>> weeks if possible.
> It looks like we're mostly there already.
Great news. Definitely will help to convince my boss.
>> We also need a diff program that understands Arabic, so any estimates
>> for adapting any diff tool to support Arabic with Subversion would be
> This is going to be tricky. svn's internal diff abilities only work
> on ascii or UTF8 data right now -- no other encodings. But svn has
> the ability to use 'external' diff programs, so it should be
> relatively straightforward to configure your users' svn clients invoke
> some sort of Arabic diff tool.
Ah, there's the rub. I've done light testing of 20+ free and
commercial diff tools and have yet to find one that works reasonably
well with Arabic. I'm not quite sure what you mean by 'only work
on...UTF8'; to me this implies it should work for any Unicode string in
utf8 packaging, so it should work for utf8-encoded Arabic. No? For
us, utf8 is sufficient, but the display has to handle arabic glyph
shaping and rtl properly. I think some of the tools do the diff ok but
just can't display the results properly. Any suggestions would be much
appreciated, and as I mentioned if the price isn't too high I might be
able to pry some dollars out of our project to support development.
Thanks again for the lightning response.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Nov 29 06:05:19 2004