If portable Firefox is an earlier version (say before FF 17), it won't work. You need to be running a recent version of Firefox. In any case that's a peculiar environment, so let's not worry with it for testing, at least.
I'm not sure why the plugin would fail in MLZ on you. It works here. I'll have to think about that one.
To confirm, you're getting the "X" and "Y" in Zotero 4.0.8, but the parens are wrongly formatting (reversed)? If so, Word is messing things up on its own, and we'll have to figure out how to apply a hack to work around its broken code in that specific environment.
Needs some more thought, I'll post again when I have more questions.
Apologies for going of the radar - it's getting quiet
hectic with the all of the end-of-the-year activity...
Any thoughts on how to hack around Word?
I wanted to let you know that I have asked a friend,
Nadav Kavelerchik (open source is his profession),
to look at this bug. Perhaps with his experience in
RTL will open up some new avenues.
He said he'd find some time to look into it.
That would be great. From your reports, it seems Word is doing something very odd there -- it is not honoring the text-direction hints in the string for some reason, so it will need a kludge to get it to behave "correctly".
I have my finger on the portion of code where the parens can be forced to reverse, but it will take a little time to work out how to detect the environment.
Hi,
I spoke with Nadav. He said that there were those problems
traslating OpenOffice, but they were able to fix the code in OO.
That's probabaly the reason it works there.
He wanted to look at the macro but editing was not available to
in Word on my computer.
In any case, he suggested [I'm for sure getting this wrong...]
using the RLE (right to left embedding) hidden code. I assume you
know this but wanted to forward his first suggestions.
That's very useful to know. It sounds like we're on the right track: the revisions I've send out so far have been using hidden codes, so it's probably just a matter of a tweak here and there.
In a related, somewhat embarrassing item, I discovered yesterday that the patch plugins I have issued recently have been non-functional. Could you try installing the latest and see if it does anything useful? (It may not, but at least it will be real test of the code this time.)
I just tested with the processor you posted,
but I dont get the X/Y near the parens in
Chicago(author-date)-mode. So I'm not sure its
working...
Does this version the prosessor give this output?
Please advise.
It's a production release, so no X or Y markers. There are several ways to control parens, this release incorporated one of them. They still don't come out correctly, I take it?
Indeed parens are still backwards :< Forgot to say that after installing the processor FF asked to be restarted. But I'd still like to be sure that it is indeed functioning...
The reboot installer definitely installs the alternative citation processor, we used that method for a year or more with no failures. The problem is just that the hidden Unicode character combination I'm using isn't solving the problem. I'll try another strategy soon and post again.
The selection of RTL vs LTR on the citation as a whole seems to be the root of the parens-reversal issue. Parens have a "weak" direction attribute, so in running RTL text, the parens will (or at least can) be treated as RTL, while the text they contain is LTR. That would produce the effect we're seeing.
The solution seems be to force each in-text citation, as a whole and including the parens, to be LTR. There are two worries with this approach. One is that the hidden Unicode characters involved might cause unexpected side effects on some systems, or (due to the clutter in the byte stream of the citation) make debugging more cumbersome. The risk there is probably acceptable, at least in MLZ.
The second, more serious worry is with documents containing a mixture of LTR and RTL citations. The thread linked above will be the place for that discussion.
If you could take a look at the thread linked above, and indicate the preferred format for LTR cites in RTL text in your environment, it will help me to get a handle on the requirements. Many thanks!
It seems that this is definetly something impotant to many people.
I'm confused- he doesn't have the same problem with the parens I do.
Is it because he changed the CSL?
I will ask on that thread.
It is indeed important in RTL. I think the issue posted there is with combinig special characters (:) inside the parens. Hoevwver, it looks
like the "correct" logical format for numbers.
Probably the reason I didn't bring it up was because at the moment I
do not have that need in the papers my students write (most citations
are journal articles). So Ididn't test for it.
But perhaps in the future....
I did try just now to add page numbers. Word mangled everthing up,
with LO it worked better but the page numbers are "backwards".
I'll post in the paralell thread to see what he did, and see
how I can reprosuce his results.
...On another note...
Perhaps it is possible to dictate direction via Language setting,
for each citation. Even LTR references with Language set to an RTL
languge could be formated "backward"?
The RTL logic works so that text is right-to-left- but numbers stay left-to-right. So I think the citations have to be formatted really "weird" for it to work.
The RTL languages are problematic for computers (I remember when the
BIOS on PCs had to be flashed to even support RTL characters).
I hope that you can find a solution fo that Word behaves like LO.
I'd like to back up and try something very simple.
In the style try setting:prefix="(&#x200e;" andsuffix=")&#x200e;" That is, without reversing the parens. If this works (touch wood), we can move on to the ordering issues within the citations themselves.
Sorry for disappearing butI just finished two summer courses
and graded most of the exams/reports.
I tried your last suggestion and got all confused. I'll try
again tonight and let you know.
I've updated the syllabus to the course I teach to include
LibreOffice, just in case we can't get Word working before
Nov/Dec. At least there everything works the way it should.
However, I think it would be more relavant to the students
if they could use Zotero in Word.
OK, this is what I found:
1) if I reverse the parens in- suffix=")" to suffix="("
then parens one on the left of the citation is correctly positioned.
2) no matter which parens I used for the prefix "(" or ")" the right-
hand parnes is always misformatted.
It seems wierd that one would work while the second wouldn't.
Well I guess it's half-way?
A couple of questions:
1) I don't know the code you used for the parens from Jun 23. Could
you point me to a reseource with info on these codes?
2) In my tests I used "Replace All" so other things on now all wrong.
Which section in the style file do I need to change?
3) The changes to the style caused the parnes to be the same for Hebrew and English citations. It may sort itself out if we can get
the correct code? If not- is there a way for Zotero to use different
styles (or different sections in the style file) for different
languages?
I'm new to Zotero, I tried looking through the code for this problem (I'm a Hebrew user). I noticed that InvokeHelper() is used for inserting refs. This function does not pass locale information.
@michaedav: I'd like to improve RTL handling, but as you can tell from the slow progress of this thread, I'm out of my element here.
Could you post to zotero-dev (a Google group)? You're more likely to attract the attention of the core devs in that forum (Simon is the author of the word processor plugins, and would be the one to answer your query).
Until now this problem is unsolved. However, i found a solution to fix the reversed parentheses in Rtl text citation in Ms Word. just select the citation text inserted by Zotero word plug-in and apply the "Rtl Run" Command. "Rtl Run" Command is a hidden command in Ms-Word which you can bring up to the Quick Access toolbar.
Upgrade Storage
I'm not sure why the plugin would fail in MLZ on you. It works here. I'll have to think about that one.
To confirm, you're getting the "X" and "Y" in Zotero 4.0.8, but the parens are wrongly formatting (reversed)? If so, Word is messing things up on its own, and we'll have to figure out how to apply a hack to work around its broken code in that specific environment.
Needs some more thought, I'll post again when I have more questions.
Yes, parens are reversed in Word.
Totaly agree that testing should be on a normal firefox
installation, and will do so from now on.
Apologies for the mix-up...
Apologies for going of the radar - it's getting quiet
hectic with the all of the end-of-the-year activity...
Any thoughts on how to hack around Word?
I wanted to let you know that I have asked a friend,
Nadav Kavelerchik (open source is his profession),
to look at this bug. Perhaps with his experience in
RTL will open up some new avenues.
He said he'd find some time to look into it.
Thanks,
David
I have my finger on the portion of code where the parens can be forced to reverse, but it will take a little time to work out how to detect the environment.
I spoke with Nadav. He said that there were those problems
traslating OpenOffice, but they were able to fix the code in OO.
That's probabaly the reason it works there.
He wanted to look at the macro but editing was not available to
in Word on my computer.
In any case, he suggested [I'm for sure getting this wrong...]
using the RLE (right to left embedding) hidden code. I assume you
know this but wanted to forward his first suggestions.
Does this help?
In a related, somewhat embarrassing item, I discovered yesterday that the patch plugins I have issued recently have been non-functional. Could you try installing the latest and see if it does anything useful? (It may not, but at least it will be real test of the code this time.)
but I dont get the X/Y near the parens in
Chicago(author-date)-mode. So I'm not sure its
working...
Does this version the prosessor give this output?
Please advise.
Forgot to say that after installing the processor
FF asked to be restarted. But I'd still like to be
sure that it is indeed functioning...
Before I attempt the next fix, I'm musing about the problem of mixed text. See this thread:
https://forums.zotero.org/discussion/30429/?Focus=159443#Comment_159443
The selection of RTL vs LTR on the citation as a whole seems to be the root of the parens-reversal issue. Parens have a "weak" direction attribute, so in running RTL text, the parens will (or at least can) be treated as RTL, while the text they contain is LTR. That would produce the effect we're seeing.
The solution seems be to force each in-text citation, as a whole and including the parens, to be LTR. There are two worries with this approach. One is that the hidden Unicode characters involved might cause unexpected side effects on some systems, or (due to the clutter in the byte stream of the citation) make debugging more cumbersome. The risk there is probably acceptable, at least in MLZ.
The second, more serious worry is with documents containing a mixture of LTR and RTL citations. The thread linked above will be the place for that discussion.
If you could take a look at the thread linked above, and indicate the preferred format for LTR cites in RTL text in your environment, it will help me to get a handle on the requirements. Many thanks!
It seems that this is definetly something impotant to many people.
I'm confused- he doesn't have the same problem with the parens I do.
Is it because he changed the CSL?
I will ask on that thread.
It is indeed important in RTL. I think the issue posted there is with combinig special characters (:) inside the parens. Hoevwver, it looks
like the "correct" logical format for numbers.
Probably the reason I didn't bring it up was because at the moment I
do not have that need in the papers my students write (most citations
are journal articles). So Ididn't test for it.
But perhaps in the future....
I did try just now to add page numbers. Word mangled everthing up,
with LO it worked better but the page numbers are "backwards".
I'll post in the paralell thread to see what he did, and see
how I can reprosuce his results.
Thanks,
Perhaps it is possible to dictate direction via Language setting,
for each citation. Even LTR references with Language set to an RTL
languge could be formated "backward"?
The RTL logic works so that text is right-to-left- but numbers stay left-to-right. So I think the citations have to be formatted really "weird" for it to work.
The RTL languages are problematic for computers (I remember when the
BIOS on PCs had to be flashed to even support RTL characters).
I hope that you can find a solution fo that Word behaves like LO.
In the style try setting:
prefix="(&#x200e;"and
suffix=")&#x200e;"That is, without reversing the parens. If this works (touch wood), we can move on to the ordering issues within the citations themselves.
suffix=")"
don't work.
Sorry for disappearing butI just finished two summer courses
and graded most of the exams/reports.
I tried your last suggestion and got all confused. I'll try
again tonight and let you know.
I've updated the syllabus to the course I teach to include
LibreOffice, just in case we can't get Word working before
Nov/Dec. At least there everything works the way it should.
However, I think it would be more relavant to the students
if they could use Zotero in Word.
Thanks again,
David
1) if I reverse the parens in- suffix=")" to suffix="("
then parens one on the left of the citation is correctly positioned.
2) no matter which parens I used for the prefix "(" or ")" the right-
hand parnes is always misformatted.
It seems wierd that one would work while the second wouldn't.
Well I guess it's half-way?
A couple of questions:
1) I don't know the code you used for the parens from Jun 23. Could
you point me to a reseource with info on these codes?
2) In my tests I used "Replace All" so other things on now all wrong.
Which section in the style file do I need to change?
3) The changes to the style caused the parnes to be the same for Hebrew and English citations. It may sort itself out if we can get
the correct code? If not- is there a way for Zotero to use different
styles (or different sections in the style file) for different
languages?
Sorry for the noob questions.
Thanks,
David
I'm new to Zotero, I tried looking through the code for this problem (I'm a Hebrew user).
I noticed that InvokeHelper() is used for inserting refs.
This function does not pass locale information.
see for example: http://kbalertz.com/246501/Explicit-Locale-Identifier-Automating-Excel-Currency-Formats.aspx
could this be the issue?
I tried loading the project into vs2012 EE, but MFC is not supported.
In what environment is this project developed?
Muchael
Could you post to zotero-dev (a Google group)? You're more likely to attract the attention of the core devs in that forum (Simon is the author of the word processor plugins, and would be the one to answer your query).