Re: [translate-pootle] Still problems committing with git
Hi, > > If the code to support older git versions is available, we obviously use it, > > but I'm not too concerned about halting anything just to support all > > versions. > > I agree. Thus I will add a module for git<1.5.2 within the next days. > I hope, that it will work for git 1.4.x, too. I just committed the additional git module for versions prior to 1.5.3. The version control interface will choose the module that fits to your locally installed version of git. Since I am not actively using git, I could only test the "getcleanfile" function of the interface (for git: "cat-file" (v1.4.4) or "show" (v1.5.3)). The other functions like "update" and "commit" are not tested, yet. I would be happy, if someone could check these features as well. I just closed the bug report. Please reopen it, if necessary. http://bugs.locamotion.org/show_bug.cgi?id=347 Lars - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Translate-pootle mailing list Translate-pootle@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/translate-pootle
[translate-pootle] Pootle, UTF-8 and bzr (was: Re: [m...@msapiro.net: Re: [Mailman-i18n] Using Pootle]
HI everyone :) On 03/07/2008, at 3:22 AM, Cristóbal Palmer wrote: Hmm, actually just visiting a file with broken stats will get Pootle to recompute the stats :). So no need to delete anything. Cheers Wynand Awesome! Yeah, it looks like this has fixed things. We'll ping back if we run into other problems, but it looks like this closes this issue. Yay! I had checked out Mailman dev branch, and was all set to convert the old formats, but now I don't have to. However, I will post to the Mailman-i18n list a reminder that UTF-8 is the standard format. It's not a major task to update your files to UTF-8. Cristóbal, are the files on Mailman from the development branch? It's important to have the current files up on Pootle, so we can encourage translators to start using it. They can download to backup their work (it's good practice, anyway). I hope these two brz links come in handy: Bzr tutorial: http://bazaar.canonical.com/IntroductionToBzr Bzr wiki: http://bazaar.canonical.com/Bzr I have also copied for myself (probably from the Bzr wiki) a comparison of SVN and bzr: I'll paste it under my sig. from Clytie Vietnamese Free Software Translation Team http://vnoss.net/dokuwiki/doku.php?id=projects:l10n __ BZR compared to SVN Getting a checkout In the SVN world, somebody has already setup a SVN repository and has told you a URL to "checkout". You checkout with: $ svn checkout URL • Usually the URL is a svn:// url, like the below example: $ svn checkout svn://somemachine.com/this/directory/here However, in the Bazaar world, this is usually done with: $ bzr checkout http://somemachine.com/this/directory/here Updating a checkout In the SVN world you may have done a checkout. From time to time you have to get new changes from the repository and apply them to your checkout. This usually looks something like this: $ cd codebase/ $ svn update This looks very similiar in the Bazaar world: $ cd codebase/ $ bzr update In both the SVN and Bazaar cases this will mean that the changes in the repository or branch that you do not yet have in the working tree will be applied. You might have to deal with conflicts. Seeing how a working tree has changed since the last commit In the SVN world we often want to check how we have changed things since we last committed. By checking how the code base has changed, we can see what we're about to commit before we actually perform the commit. In the SVN world, we would check the changes this way: $ svn status [see a list of files that have changed] $ svn diff [see a diff of how files have changed] This is very similar in Bazaar: $ bzr status [see a list of files that have changed] $ bzr missing [see a list of new revisions in the parent branch] $ bzr diff [see a diff of how files have changed] In both of these cases, you'll get a diff that you can review prior to commit. Comitting code in a checkout In the SVN world you may have made changes to your checkout that need to be saved in the repository. One typically does so in this way: $ svn commit -m'some description of whats being committed.' Again, this looks very similiar in the Bazaar world: $ bzr commit -m'some description of whats being committed.' In both of these cases, the new changes will be saved to either the repository (SVN) or branch (Bazaar). Section 2 - Using Branches to perform SVN migration Bazaar supports a variety of other development methodologies that are foreign to SVN developers. These methodologies typically work much better than the SVN method. They are, however, a bit different from the CVS way. Section 3 - Development methodologies Loose Cannon Style General Rules • Each developer makes and maintains their own branches. • Developers merge each other ad-hoc • No coordination of merges between branches Benefits • Everyone gets their own itches scratched • Developers do not need to like each other • Highly competitive environment. Drawbacks • Branches will become highly diverged. • Users will be confused about which branches to follow • Branches will likely diverge into different projects Shared Branch Style General Rules • There is one proto-branch that all developers can push to and from • Developers may have local branches that individual features are worked on and then merged into the proto-branch Benefits • The branch for users to follow is clear and obvious • Development is not held up if one developer goes on vacation Drawbacks • Developers can put code into the proto-branch without test cases being run. • Contention for pushing into the proto-branch may become an issue if there is a large number of commit-happy developers. The Lieutenant Style General Rules • Needs to be combined with anoth
Re: [translate-pootle] Cookie-based login
On 02/07/2008, at 10:57 PM, Julen wrote: Does anybody else struggle with this? I am automatically logged in after closing my browser. I'm using Firefox on Linux. I agree that this would be useful, I was just under the impression that this already works. Can people help to gather the necessary information to track this down? Friedel I'll check the timeout values for the cookies. Perhaps the timeout is too short and if so, we could allow users to specify longer timeouts. In Firefox,, if you go to Privacy settings and view the stored cookies, it tells that the cookie (Pootle-session) expires at the end of the session, i.e., when you close your browser. So in order to keep the login through sessions, it is necessary to set an expiration date. Interesting how different browsers handle cookies differently... Firefox does have the option to let the cookie persist until its own expiry date: I already had that option selected, and my various Pootle cookies have dates well into the future. So the auto-relogin is definitely not working in Firefox for OSX Intel. Camino doesn't have a time-related option for cookies, and all my Pootle cookies are set to expire On Quit, although many other sites are not. (Drat: Camino displays the whitespace markers, while Omniweb does not, so I'd started using Camino for all my Pootle tabs.) Omniweb allows cookies to persist, like Firefox, and again like Firefox, the Pootle cookies have expiry dates in 2008 and 2010, but auto-relogin still doesn't work. So different browsers are setting different expiry dates for Pootle cookies, as well as handling them differently. from Clytie Vietnamese Free Software Translation Team http://vnoss.net/dokuwiki/doku.php?id=projects:l10n PGP.sig Description: This is a digitally signed message part - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08___ Translate-pootle mailing list Translate-pootle@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/translate-pootle
Re: [translate-pootle] Viewing suggestions while translating
On Wed, 2008-07-02 at 13:29 +0200, Julen wrote: > On Mon, Jun 30, 2008 at 1:14 PM, Julen <[EMAIL PROTECTED]> wrote: > > > > I've written a blog post[1] about the topic so you can have a more > > concrete overview of what's going on. Probably a screencast should be > > fine to show the AJAX part but my computer is not powerful enough for > > video stuff. Anyway, I think the screenshot + the demo[2] is enough to > > have an overall perspective of this. > > I've managed to record a screencast, it's available at: > http://ertza.murgilduta.net/wp-content/uploads/2008/07/view_suggestions.ogg > (280K) I watched this on Friedel's computer while we're on conference in a Game Reserve (jut said that to make everyone jealous). This looks great! Thanks for all the effort -- Dwayne - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Translate-pootle mailing list Translate-pootle@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/translate-pootle
