From jamie-list at tramchase.com Sat Aug 4 12:09:59 2007 From: jamie-list at tramchase.com (Jamie Wilkinson) Date: Sat, 4 Aug 2007 12:09:59 -0400 Subject: [Retrospectiva-general] 1.1 authentication extensions Message-ID: I have an ldap_auth extension I wrote way back in the day I was trying to revive, but it doesn't seem to play with 1.1 (or 1.0 for that matter). Does an auth extension need to do everything being done in openid_auth with the latest and greatest? Any and all hints appreciated, -jamie --- Jamie Wilkinson _____________ mailto:jamie at tramchase.com ________ aim:jwilksdub -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/retrospectiva-general/attachments/20070804/10b7a75f/attachment.html From kou at cozmixng.org Mon Aug 6 07:25:15 2007 From: kou at cozmixng.org (Kouhei Sutou) Date: Mon, 06 Aug 2007 20:25:15 +0900 (JST) Subject: [Retrospectiva-general] localization again Message-ID: <20070806.202515.148858211.kou@cozmixng.org> Hi, I tried to translate messages into Japanese but I noticed RetroI18n doesn't have some useful features for translating what I was mentioned a few months ago: * We can't jump to where the message is used. We need to know a context where the message is used. A word or a sentence is not good enough. * Retrospectiva can't change the current locale per request. ApplicationController#set_locale set the current locale literally. We will be able to use HTTP_ACCEPT_LANGUAGE variable to change the current locale for each request. * Retrospectiva doesn't reload language files automatically even if we are in a development environment. We will need to use try & error (translate & check) method to translate messages for avoiding strange translation. Auto-reloading message files feature helps the process. If the feature is lacked, we need to work with some frustrations. Dimitrij, I think your works are great as I mentioned ago but RetroI18n is needed more work to be useful module. And there are already some useful modules such as Ruby-Gettext-Package. (*) They already implemented useful features and continue developing. Could you use one of them instead of RetroI18n? I want you to develop other useful Retrospectiva features because your time is limited. And translators (including me) will be happy with more useful features for translating. (*) Other modules were pointed out a few months ago. I'm sorry if my request harms you... Thanks, -- kou From contact at dvisionfactory.com Mon Aug 13 02:53:45 2007 From: contact at dvisionfactory.com (Dimitrij Denissenko) Date: Mon, 13 Aug 2007 07:53:45 +0100 Subject: [Retrospectiva-general] localization again In-Reply-To: <20070806.202515.148858211.kou@cozmixng.org> References: <20070806.202515.148858211.kou@cozmixng.org> Message-ID: <46BFFFF9.80805@dvisionfactory.com> Hi Kou! > * We can't jump to where the message is used. This is something I planned to work on next. > Retrospectiva can't change the current locale per request. > It can, but it's not built-in yet, since RetroI18n is only a draft. > Retrospectiva doesn't reload language files automatically even if we are in a development environment. > Again, RetroI18n is only a draft yet. This is a very useful feature and I could easily fix/implement it. Generally, your request does NOT harm me at all, quite the opposite, I like constructive criticism, that's the reason why I haven't spend much time on RetroI18n. I just quickly coded a draft for a possible solution (because I wasn't able to find a proper available package). If you think (as a translator), that other packages would are more valuable, that's perfectly fine for me, I will look into them. To save my time, could you please (once again) make a quick list of potential candidates (with their strengths and weaknesses), just a few lines. Many, many thanks. Kind regards Dimitrij PS: Kou, did you have time to look into the GC issue? Is it solved in 1.4.2? From kou at cozmixng.org Mon Aug 13 08:31:56 2007 From: kou at cozmixng.org (Kouhei Sutou) Date: Mon, 13 Aug 2007 21:31:56 +0900 (JST) Subject: [Retrospectiva-general] localization again In-Reply-To: <46BFFFF9.80805@dvisionfactory.com> References: <20070806.202515.148858211.kou@cozmixng.org> <46BFFFF9.80805@dvisionfactory.com> Message-ID: <20070813.213156.130003331.kou@cozmixng.org> Hi, > > * We can't jump to where the message is used. > This is something I planned to work on next. > > > Retrospectiva can't change the current locale per request. > > > It can, but it's not built-in yet, since RetroI18n is only a draft. > > > Retrospectiva doesn't reload language files automatically even if we are in a development environment. > > > Again, RetroI18n is only a draft yet. This is a very useful feature and > I could easily fix/implement it. Of course I know you can implement them if you have a time. :) > Generally, your request does NOT harm me at all, quite the opposite, I > like constructive criticism, that's the reason why I haven't spend much > time on RetroI18n. I just quickly coded a draft for a possible solution > (because I wasn't able to find a proper available package). If you think > (as a translator), that other packages would are more valuable, that's > perfectly fine for me, I will look into them. To save my time, could you > please (once again) make a quick list of potential candidates (with > their strengths and weaknesses), just a few lines. Many, many thanks. OK. (I'm sorry. I can't describe that in a few lines.) In first, I suggest you to choice Ruby-GetText-Package. If you choice that, I can make a patch to support that. I selected two components, Globalize and Ruby-GetText-Package, from this table: http://wiki.rubyonrails.org/rails/pages/InternationalizationComparison At least I need to the following functions: 1) Extract strings automatically (for maintaining translated messages) 2) Support tools to maintain (for maintaining translated messages) 3) Multi textdomain (for supporting extensions) 4) Auto finding the client locale 5) Development is continued (IMPORTANT!) Globalize: 1) Needless 2) Web Interface for translating (if we make) 3) Yes 4) No (some sample implementations are available) 5) Yes Ruby-GetText-Package: 1) Yes 2) Yes (we can use our favorite text editor or propose-built editor for translating) 3) Yes 4) Yes (built-in) 5) Yes RetroI18n: 1) Yes 2) Not yet 3) Yes 4) Not yet (in the repository) 5) Yes Globalize's the worst weakness is that Globalize doesn't care distribute translated messages. The messages are stored our own databases. We have a database each other. How do distribute our translated message? SQL dump? How do we merge distributed SQL dump? So I don't want you to choice Globalize. Ruby-GetText-Package has features what I need to translate messages and has same interface as RetroI18n. (#_() is used to translate a message.) And it supports ActionMailler too. (only Japanese...) It has many strengths but its source is tricky and ugly... (We will not touch the source because Ruby-GetText-Package is well maintained but ...) RetroI18n's weaknesses are the author's doesn't have a time to develop that and that is needed more work to use... > PS: Kou, did you have time to look into the GC issue? Is it solved in 1.4.2? The following is the result on my environment: Loaded suite test/other/memory_test Started [+] Started 'test_01_syncronization' (VIRT 45924 kB, RES 34976 kB, VDIFF 0 kB, RDIFF 0 kB) [=] Finished after 0s (VIRT 45924 kB, RES 34976 kB, VDIFF 0 kB, RDIFF 0 kB) . [+] Started 'test_02_process_changed_nodes' (VIRT 45924 kB, RES 34976 kB, VDIFF 0 kB, RDIFF 0 kB) Processing 10000 nodes Status after 2000 nodes (VIRT 61324 kB, RES 50080 kB, VDIFF 15400 kB, RDIFF 15104 kB) Status after 4000 nodes (VIRT 62504 kB, RES 51424 kB, VDIFF 1180 kB, RDIFF 1344 kB) Status after 6000 nodes (VIRT 63544 kB, RES 52524 kB, VDIFF 1040 kB, RDIFF 1100 kB) Status after 8000 nodes (VIRT 67000 kB, RES 55808 kB, VDIFF 3456 kB, RDIFF 3284 kB) [=] Finished after 325s (VIRT 67300 kB, RES 55852 kB, VDIFF 300 kB, RDIFF 44 kB) . [+] Started 'test_03_changeset_browsing' (VIRT 67300 kB, RES 55852 kB, VDIFF 0 kB, RDIFF 0 kB) Processing 400 changesets Status after 200 changesets (VIRT 70296 kB, RES 58956 kB, VDIFF 2996 kB, RDIFF 3104 kB) Status after 400 changesets (VIRT 70308 kB, RES 58964 kB, VDIFF 12 kB, RDIFF 8 kB) [=] Finished after 164s (VIRT 70296 kB, RES 58964 kB, VDIFF -12 kB, RDIFF 0 kB) . [+] Started 'test_04_node_browsing' (VIRT 70296 kB, RES 58964 kB, VDIFF 0 kB, RDIFF 0 kB) Browsing through revision 900 [=] Finished after 84s (VIRT 80224 kB, RES 68004 kB, VDIFF 9928 kB, RDIFF 9040 kB) . Finished in 575.262605 seconds. 4 tests, 1044 assertions, 0 failures, 0 errors My environment: * ruby 1.8.6 (2007-06-07 patchlevel 36) [i486-linux] * Retrospectiva: r166 * Subversion: 1.4.4 PS: Did you get my patch for SQLite3? Index: app/models/ticket_property_global.rb =================================================================== --- app/models/ticket_property_global.rb (revision 156) +++ app/models/ticket_property_global.rb (working copy) @@ -56,9 +56,9 @@ end def before_save - self.class.update_all(:default_value => false) if self.default_value? + self.class.update_all(["default_value = ?", false]) if self.default_val ue? end end -end \ No newline at end of file +end Thanks, -- kou From rusty at soapboxsoftware.com Tue Aug 28 23:54:41 2007 From: rusty at soapboxsoftware.com (Rusty Geldmacher) Date: Tue, 28 Aug 2007 23:54:41 -0400 Subject: [Retrospectiva-general] Fix for new plugins causing server startup failures? Message-ID: Hi all, I was just looking around the Retrospectiva wiki and noticed a blurb in the Extensions page about installing the Timeline plugin. Basically it said that to install the plugin, one needs to manually add the 'timeline' item to the menu.yml file, since menu_map will fail during initialization. Sure enough, that's true but I found a workaround for that, and wanted to run it by the list. The crash is in the sort_by! method of Retrospectiva::AccessManager::MenuMap when it's trying to sort the names of the menu items. The first line of that method is: names &= self.item_names which does a set intersection of the current item names with the item names in the menu.yml file. Now, I really don't know the Retrospectiva code base very well, but I believe that line might have been intended to be a set union instead: names |= self.item_names That way, the new menu item you are pushing on to the menu map will not get removed from the names array, and then the sort won't fail. This change works for me, and makes it so I don't need to manually add anything to menu.yml file when installing plugins. Is this change correct? In other words, is this the behavior that was originally intended? I hope I made sense here ;) rusty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/retrospectiva-general/attachments/20070828/9aebca50/attachment.html