Basel Shishani's profile - activity

In the file

../askbot/skins/default/templates/widgets/scope_nav.html

There are 3 strings that are not exposed to the translation system:

'ALL', 'UNANSWERED' and 'FOLLOWED'

Q: We are supposed to report bugs in this QA section, correct?

Update:

Here's another one that has slipped through:

.../askbot/skins/default/templates/question/answer_tab_bar.html :10
        <span class="label">
        Sort by »
        </span>

I can see that Xapian readily provides functionality for finding a set of documents similar to a given one; I guess Lucene would have something equivalent. See: [http://trac.xapian.org/wiki/FAQ/FindSimilar], [http://trac.xapian.org/wiki/FAQ/EliteSet]. We would just need to fiddle with the factors specific to a QA forum, (namely the relative weights for title/tag/question/answer terms) to try to optimize the relevance.

I think in an earlier post Evgeny mentioned that work is being done on integrating Haystack. So when probabilistic search is used say by plugging Xapian or Lucene, search will behave much more sensibly - right?!

@Evgeny: Can you provide an indication on when the Haystack code would be added to master? Waiting on this eagerly.

Is it possible to integrate the contrib.flatpages app into Askbot?! If that was possible then would help with the basic use cases of adding a page here or there. I thought I read somewhere on the Askbot QA forum that it was not possible because of the way Askbot uses skins, but can't find that piece of info again.

First: adding blank/whitespace tags:

The system allows empty/whitespace tags to be added to the list of interesting or ignored tags, and an empty box with an X next to it shows in the list of tags. This should not be allowed, so checks should be done both at the client and the server side to prevent this from happening.

Second: adding non-existent tags:

The system allows users to add tags that are non-existent (non existent on the system and have not been applied to any question). The merit of this could be open to debate (like is the user going to watch for possible future tags!?), but the more pressing thing is that these tags currently have no effect on excluding questions. This creates the following situation: the user adds a tag to the interesting tags, and selects 'only interesting tags', but gets no effect for his actions, which would be confusing. So: if such tags are to be allowed, things should be taken to their logical conclusion, showing no questions if the tag is non-existent.

Third: handling the display of excluded questions:

This is a usability take on the issue of displaying question that have been excluded as a result of the choices made either with the interesting or ignored tags.

One style - as used by Askbot - is to hide the excluded questions. This has the draw back that the user might forget that she had changed the settings on interesting/ignored tags, and wonder why questions are not showing up in a search.

Another style - as used in StackOverflow (I'm not sure if this feature is user configurable) is to dim out the excluded questions and highlight the interesting questions. This has the draw back that if the excluded question are truly of no interest then there mere display is annoying to the user.

I suggest the following style for consideration: the Askbot style of hiding excluded questions can be used with the following improvement: When a selection that causes exclusion of some questions is in effect, we can provide feed back about it by displaying heading messages as such:

"Only showing question from interesting tags" or

"Excluding questions from ignored tags"

Maybe a good spot for these messages is next to the heading for the count of messages - so we can have in the heading:

16 Questions - (Only showing questions from interesting tags)

In short: the selections and tag lists on the side would not be the only feedback the user can get about the current state of the system, as these can be easily overlooked.

There is buggy behavior when updating the tags in the interesting/ignored tags on the main page:

If the window URL contains URL encoded non ascii chars (as in internationalized url's where the 'question' segment has been translated) then the refreshed URL after the Ajax call would get mangled (the non-ascii segment goes through incorrect encode/decode it seems). Also, the newly added/removed tags would not show immediately on the page, but would show on subsequent page updates.

This seems to be an issue not with Askbot but with the History.js library - when calling History.pushState.

I modified the code in the 'livesearch.js' file to call history.pushState directly (notice the lower case 'h') bypassing the History.js library, and the issue went away as far as I can tell. (Of course by doing so we lose the supposed benifit of History.js)

I provide more details in my recent StackOverflow posting, so check it there please.

Revisiting an old issue: I was recently testing on G Chrome running on http://127.0.0.1:8000/, and getting the "CSRF verification failed" error. Initially, I had /DOMAIN_NAME = 'localhost'/, so I switched to /DOMAIN_NAME = ''/ as you point out, and the error went away. But then I switched back to /DOMAIN_NAME = 'localhost'/, and the error is not there anymore on subsequent server runs. So somewhere it seems there is a bug/feature where DOMAIN_NAME = 'localhost', will not work initially, but will work if the cookie has been set earlier by using the blank domain name (?!).

Last night I pulled the latest dev master from github (commit fabb3a), and when I tried jinja2-makemessages, I got the error "SyntaxError: Translation blocks must not include other block tags: ..." on two template files:

skins/default/templates/email/macros.html
skins/default/templates/email/post_as_subthread.html

There is no block tag issues to my eye, but the errors went away when I removed the minus signs in the {%- endtran %} and {%- pluralize %} tags.

So it seems that jinja2-makemessages is getting confused over the whitespace control minus signs in the tags - is there such an issue?

Last night I pulled the latest dev master from Github (commit fabb3a), and when I tried jinja2-makemessages, I got the error "SyntaxError: Translation blocks must not include other block tags: ..." on two template files:

skins/default/templates/email/macros.html
skins/default/templates/email/post_as_subthread.html

There is no block tag issues to my eye, but the errors went away when I removed the minus signs in the {%- endtran %} and {%- pluralize %} tags.

So it seems that jinja2-makemessages is getting confused over the whitespace control minus signs in the tags - is there such an issue?!

The separation of javascript messages into a separate domain (eqv to namespaces) is natural as the catalog might be passed to the client (am not sure if that's how askbot does things). There are other good reasons to have namespaces for messages. The blame should be squared on the deficient gettext where you can't provide inter-references between message entities in different domains (this is just a minor issue compared to its many shortcomings).

And the workaround you pointed to is to work around a shortcoming in jinja2_makemessages when handling template files. So there are two separate issues, one re template files (which is more or less resolved), and another with js files, which is the subject of this posting. Regards.

The command you provided works for the generic domain, for Javascript files a separate domain (djangojs) is used. I edited the question to add examples. jinja2_makemessages does not improve on makemessages when it comes to js, it's meant to improve handling template files.

There are known issues with gettext message exraction for js files. makemessages skips aronud a third of the messages (in askbot). xgettext does not support js, but can be used with --language=python, but still skips messages.

[

To use makemessages with javascript message in a separate djangojs domain:

manage.py makemessages -d djangojs -l fr

(makemessages understands that this domain is for messages from js files - by the look of it)

To use xgettext, which works only on individual files:

xgettext --language=python --from-code=utf-8  post.js

]

I posted a question about the Babel extractor on SO here, which their docs say can be used for js message extraction, but didn't get an answer.

I'm wondering what others who are localizing askbot are using for this, maybe you're using your own concocted script or doing it manually, or you know some better tool.

I thought to raise this here anyway as others might hit the issue.

I think that was accidental for you. If you run makemessages again it will comment out your translations once more. The workaround explained by Evgeny works fine for now. The issue he mentioned is explained in detail in the jinja2_makemessages module doc.

And just a small correction on askbot/const/message_keys.py

Evgeny, thanks for the answer and I really appreciate the time you're devoting to this. May I ask, is this some dormant bug in (jinja2_)makemessage to be addressed at some point in the future, or is it a known/understood inherent issue in the way makemessages - gettext - templates interact together. If you have a pointer on this it will do me.

According to this question jinja2_makemessages is supposed to work fine with templates. But in my latest update from the Github repo I'm noticing that some strings are being skipped. For example the sort by button labels on questions page: 'by date', 'by activity', 'by answers', 'by votes'.

Am I doing something wrong?! I'm just doing the same thing I used to do before:

python /path/to/manage.py jinja2_makemessages -l xx -e html,py,txt

So basically you would like to enforce a style or a rule for the users when they're thinking up these tags. I understand these could be enforced at a different level, or by convention, but Ideally the regex and the error message for unacceptable tags would be configurable.

One case is tech jargon, For example, if 'HTML' is to be a tag, do you use the English word or a transliterated eqv.

Another case: the Arabic code page covers other languages including Farsi and others. Some words have been borrowed from English (eg video) and contain sounds not present in Arabic (v), and are commonly written with a close alternative (f for v, b for p), but can also less commonly written with true v, p letters from the Arabic code page but not from the strict Arabic range. So basically there are alternatives that would be dictated by the allowable range.