On Tue, 30 Nov 2004 04:53:10 +0300, gar <gar@arabink.com> wrote:
> Yes, sorry, I had a problem with Arabic log msgs on my Mac client and
> rashly assumed it was a general subversion problem. It turns out
> tortoiseSVN handles them - almost. It stores them ok and they show up
> ok in the summary view of log messages, but in the detail panel (where
> the entire log message shows) I get question marks. I could send a
> screen shot if it would help.
Hmm - that's strange. If they show up correctly in the summary then
they're encoded correctly. Then there's no reason why they shouldn't
show up correctly in the detail panel too!?!?
The only difference I can see is the font used by the summary (that's
a list control) and the detail panel (rich edit control). Try choosing
a different font in the settings dialog.
> Yes, Arabic is an rtl language. But windows handles it ok, so I think
> if I were to create an Arabic .po file the Arabic would display ok.
> Might be some sizing issues. I'll let you know when I've had a chance
> to test.
I hope it will work, but I'm not sure. Is the RTL only for text or
does this apply to the layout of the dialogs too? I mean do you need
the descriptive text of a checkbox on the left side too? If that's the
case, then simply translating the strings won't be enough.
> So far I haven't had any luck getting it to display Arabic characters.
> It looks like it is doing the diff ok, but the display is gibberish.
> I've tried it with a bunch of different fonts to no avail. This is on
> Win2K sp5 with Arabic support enabled. Courier New is a monospaced
> font with Arabic support, in case you want to give it a try. I can
> provide you with a small file of Arabic text if you'd care to
> investigate.
Such a file would definitely help. But only if you provide a
screenshot of the file being shown in a texteditor which shows the
chars correctly. That way I can compare the output of TortoiseMerge
with the screenshot - otherwise I won't be able to tell if the chars I
see actually make sense or not.
> Maybe my files are missing the BOM? What's the codepoint, I'll try to
> insert it. Still, various tools I use are able to display the Arabic
> ok without a BOM (I think).
The problem with files without BOM's is that you can't tell for sure
if they're UTF8 or not. There are some guessing functions available,
but they all fail under certain circumstances. That's why I haven't
implemented such a guessing function in TortoiseMerge and only rely on
the BOM's (the only thing that's 100% sure).
> Regarding RTL alignment: it would be nice, but I can live with
> left-aligned text so long as it reads from rtl. If you were going to
> implement RTL display alignment, I would suggest linking it with a
> property, e.g. SVN:TEXTORIENTATION or the like so that TSVN display
> "does the right thing" automatically if you've set the property
> correctly. You could also try to guess the dominant alignment base on
You mean as a file property? I don't think that's a good idea. Because
sometimes different users use different languages for their log
messages (believe me: I've seen that more than once). And then an
english log message would be shown RTL too.
Best would be if there were a revision property assigned to each log
message. But that's Subversions territory, not TSVN's ...
> My ideal solution is a diff interface that displays Arabic and allows
> me to merge and do minor editing.
TortoiseMerge doesn't allow text editing (for now). Maybe it will one
day in the future.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Nov 30 09:34:36 2004