First time here? Check out the FAQ!
Ask Your Question

alexwerner's profile - activity

overview network karma followed questions activity
2023-05-12 22:43:25 -0600 received badge Taxonomist
2020-07-19 23:03:52 -0600 received badge Popular Question (source)
2020-07-19 23:02:20 -0600 received badge Famous Question (source)
2020-07-19 23:01:31 -0600 received badge Popular Question (source)
2013-07-26 16:19:37 -0600 received badge Famous Question (source)
2012-08-14 16:05:25 -0600 received badge Famous Question (source)
2012-04-11 15:18:19 -0600 received badge Good Question (source)
2011-11-29 17:53:25 -0600 received badge Nice Question (source)
2011-11-29 12:49:38 -0600 asked a question translation works only partially in templates

With the new theme (don't know about the old one), translatable strings that are inside jinja macros appear in the language they were first requested after the server startup (it seems as if jinja optimizes/caches the contents of macros).

Possible fix is not to use translatable strings inside of macros.

Setup is apache+mod_wsgi, localization using the django built in LocaleMiddleware and independently when using django-localeurl.
2011-11-25 16:14:33 -0600 commented answer How to isolate non-English questions so that English users are not annoyed by foreign questions? Or I should deploy another askbot exclusively for a language?

If you use postgresql as database and set it up with C.UTF-8 as locale, real utf-8 full text search works. Perhaps you could mention this in the documentation.
2011-11-19 03:32:07 -0600 asked a question Why are ajax urls partly translated and partly not?

When testing askbot for use in a multi language setup, I saw that ajax URLs are also partly localized (for example the vote, read_message, upload named urls).

These URLs are also hardcoded in skins/default/templates/question/javascript.html in an "interesting" way.

Shouldn't all ajax/api URLs always be language independent?
2011-11-16 16:05:58 -0600 received badge Organizer (source)
2011-11-16 16:04:54 -0600 answered a question Social sharing buttons javascript bug

Detection of blocked pop-ups and fallback to open the link in the current window is now fixed in https://github.com/ASKBOT/askbot-devel/commit/d39849bc2e73d1c9cdcb07b12fe6fdf6d562e582">git.
2011-11-16 07:39:36 -0600 received badge Supporter
2011-11-15 09:05:51 -0600 commented answer Social sharing buttons javascript bug

After looking at post.js a bit more it seems as the fallback is already implemented, but buggy: If the pop up window fails, it is tried to open the link in the current window, but the wrong variable is used.
2011-11-15 09:05:50 -0600 commented answer Social sharing buttons javascript bug

After looking at post.js a bit more it seems as the fallback is already implemented, but buggy: If the pop up window fails, it is tried to open the link in the current window, but the wrong variable is used.
2011-11-15 08:27:35 -0600 commented question Social sharing buttons javascript bug

Yes, a popup is indeed preferable... perhaps informing the user that the popup could not be opened, as clicking on the sharing buttons and nothing happens is bad behavior, I think.
2011-11-15 08:11:17 -0600 commented question Social sharing buttons javascript bug

Just looked at post.js myself: If you change the name of share_url to url, the sharing page opens in the current window if the popup cannot be opened.
2011-11-15 06:47:03 -0600 received badge Nice Question (source)
2011-11-15 06:05:37 -0600 received badge Student (source)
2011-11-15 05:24:07 -0600 received badge Autobiographer
2011-11-15 05:20:57 -0600 asked a question Social sharing buttons javascript bug

Steps to reproduce:

  • Disallow PopUps in your browser
  • Click on any of the social sharing buttons next to a question, except google+

Expected result:

  • The sharing page opens in the current window/tab

Actual result:

  • No page opens
  • Javascript error log:

ReferenceError: Can't find variable: share_url in post.js:1573

Versions affected:

  • 0.7.22 - 0.7.29
  • Skins old and default