Re: [Monotone-devel] Is l10n a little off?
In message [EMAIL PROTECTED] on Sun, 15 Jan 2006 10:20:52 +0100 (CET), Richard Levitte - VMS Whacker [EMAIL PROTECTED] said: richard In message [EMAIL PROTECTED] on Sat, 14 Jan 2006 18:25:57 -0800, Nathaniel Smith [EMAIL PROTECTED] said: richard richard njs On Sat, Jan 14, 2006 at 12:27:49PM +0100, Richard Levitte - VMS Whacker wrote: richard njs Where did you get the monotone.pot? I figured out what went wrong. Apparently, there was a short moment when the value of XGETTEXT_OPTIONS in po/Makevars was quoted, and I hadn't used config.status since... And now I have a sv_SE.po with a lot more stuff to translate. Yay, or something... Sorry about all the commotion. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Is l10n a little off?
On Sun, Jan 15, 2006 at 10:20:52AM +0100, Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Sat, 14 Jan 2006 18:25:57 -0800, Nathaniel
Smith [EMAIL PROTECTED] said:
njs It isn't checked in to the source tree, and the versions in
njs distributed tarballs are really bad, because of they were
njs generated without the fixes that I just made in the last few
njs days.
So you're saying I should really remove it and have it regenerated, is
that it? Seems to me there's a lack of proper dependency then...
$(DOMAIN).pot-update depends on $(POTFILES), which is generated from
po/POTFILES, but it looks like POTFILES.in hasn't been properly
updated, I see quite a lack of file names in it.
I'm saying whatever you have seems not to be up to date. I don't know
if that's because you haven't regenerated it, or what... actually, I
don't even know how to ask the makefile machinery in there to do
an update, I just know that every once in a while ('make dist',
mostly) make decides to regenerate the .po files -- and then I have to
revert them, because the translators get annoyed at me if I touch
those files :-).
How POTFILES.in is supposed to work also confuses me. intltool-update
--maintain says it can't find any missing files, so I've sort of been
hoping that things will just work out somehow. Or at least figuring
that if there really is a problem, it can wait until a translator
finds strings missing.
BTW, I've noticed that in my working directory, a lot of entries in
po/fr.po have been commented away... Uh-oh, and I see that I've quite
a diff in those files compared to the mainline (lucky I'm careful with
what I commit, eh? :-) I'll get back about commits, BTW). I guess
I'd better regenerate that template.
Yeah, be careful not to commit any po files you don't mean to.
Reading that page, it seems to me like the location doesn't have to be
just one unique place per system, it only has to be exactly what's
compiled into the application. So basically, as long as PACKAGE and
LOCALEDIR are correct when being used with bindtextdomain()
(monotone.cc:245), everything should work right. And it should, since
LOCALEDIR is derived from $(localedir) in Makefile, which is
$(datadir)/locale.
Sounds plausible. If you want to add a configure option or whatever
(environment variable, maybe?) to change the locale dir for testing,
go for it :-).
njs You also have to make sure your locales are properly generated;
njs this is somewhat complicated and I don't really understand it,
njs but it's per-system per-locale -- so if you can convince ls or
njs gcc or whatever to give you errors in Swedish, then this part
njs is working and you don't need to worry about it.
That's not a problem, that part works like a charm:
: ; ls -l po/monotone.pot
-rw-r--r-- 1 levitte levitte 4016 2006-01-11 20:04 po/monotone.pot
And a 'monotone-0.26pre1 pull' gives my numbers with a space inserted
every third digit in the integer half and a comma as a fraction
delimiter instead of a period.
Hmm, neither of these is really evidence, I think? The question is
whether your system has the sv locale enabled or not. (Which is a
separate question from whether your system has any other locale
enabled, and also a separate question from whether you have requested
the use of the sv locale as a user.)
The way to test is do something like:
$ LANG=sv ls -z
and see if both lines of output are localized to swedish.
njs The gettext stuff should be working in current mainline.
I'll make an extra check to see if POTFILES.in should be updated.
Cool.
-- Nathaniel
--
Damn the Solar System. Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
-- Lord Jeffrey
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Is l10n a little off?
In message [EMAIL PROTECTED] on Sun, 15 Jan 2006 02:07:41 -0800, Nathaniel
Smith [EMAIL PROTECTED] said:
njs On Sun, Jan 15, 2006 at 10:20:52AM +0100, Richard Levitte - VMS Whacker
wrote:
njs I just know that every once in a while ('make dist', mostly) make
njs decides to regenerate the .po files -- and then I have to revert
njs them, because the translators get annoyed at me if I touch those
njs files :-).
Heh, on the other hand, the same thing usually happens to the
translators as well, and I guess the worst is when you end up with a
bunch of fuzzy entries. Other than that, I don't really see the harm,
but being new at this, it would probably be good to hear from those
that have done this for a little longer...
(whiners, all of us we are :-))
njs How POTFILES.in is supposed to work also confuses me. intltool-update
njs --maintain says it can't find any missing files, so I've sort of been
njs hoping that things will just work out somehow. Or at least figuring
njs that if there really is a problem, it can wait until a translator
njs finds strings missing.
OK, I guess my next thing will be to look at the source, because I
just can't understand what selection criteria it uses. For example,
there are a number of F() used in safe_map.hh, but that one isn't
anywhere in POTFILES*...
njs If you want to add a configure option or whatever (environment
njs variable, maybe?) to change the locale dir for testing, go for it
njs :-).
Nah, I see no reason to. If it depends on --prefix, that's fine with
me.
njs That's not a problem, that part works like a charm:
njs
njs: ; ls -l po/monotone.pot
njs-rw-r--r-- 1 levitte levitte 4016 2006-01-11 20:04 po/monotone.pot
njs
njs And a 'monotone-0.26pre1 pull' gives my numbers with a space inserted
njs every third digit in the integer half and a comma as a fraction
njs delimiter instead of a period.
njs
njs Hmm, neither of these is really evidence, I think?
That's plenty of evidence that swedish dates and numbering is used, so
at least LC_NUMERIC and LC_TIME works the way it should. Plus I have
a /usr/share/locale/sv/ catalog filled with files (especially in
LC_MESSAGES)...
njs The question is whether your system has the sv locale enabled or
njs not. (Which is a separate question from whether your system has
njs any other locale enabled, and also a separate question from
njs whether you have requested the use of the sv locale as a user.)
Yes it does (I've a few variants of sv_SE in my /etc/locale.gen), and
I have locale enabled, and I do use it oh wait, I just looked in
my .bashrc, and look what I found:
export LANG=sv_SE
export LC_MESSAGES=C
AUGH! So no matter what LC_ALL I set in my command line, I'll still
get the C locale for messages! AUGH! And I've been staring at the
output from 'locale' and apparently skipped over LC_MESSAGES all the
time (all the other lines give me sv_SE)! AUGH! The frustration!
Checking: LC_MESSAGES=sv_SE monotone-0.26pre1 --help
Yes, output in Swedish!
OK, I guess that's the final straw. This issue just isn't (well,
except for the POTFILES.in thingie)...
OK, time to laugh this off...
njs The way to test is do something like:
njs $ LANG=sv ls -z
njs and see if both lines of output are localized to swedish.
: ; ls -z
ls: invalid option -- z
Try `ls --help' for more information.
njs I'll make an extra check to see if POTFILES.in should be updated.
njs
njs Cool.
Still to be done.
Cheers,
Richard
-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
--
Richard Levitte [EMAIL PROTECTED]
http://richard.levitte.org/
When I became a man I put away childish things, including
the fear of childishness and the desire to be very grown up.
-- C.S. Lewis
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Is l10n a little off?
Nathaniel Smith spake unto us the following wisdom: On Sun, Jan 15, 2006 at 02:16:40PM +0100, Richard Levitte - VMS Whacker wrote: Heh, on the other hand, the same thing usually happens to the translators as well, and I guess the worst is when you end up with a bunch of fuzzy entries. Other than that, I don't really see the harm, but being new at this, it would probably be good to hear from those that have done this for a little longer... I _think_ the point is that they want to merge in new translations at a time that they choose, rather than having it just happen (possibly creating a bunch of spurious conflicts on their end)? You can help mitigate these problems by having translatable string freezes shortly before releases, and releasing new .potfiles at that time. There are a number of tools to reconcile the existing transla- tions and newly translatable entries which the translators can use to minimize the pain. This removes the necessity of following a rapidly moving and sometimes inconsistent target (i.e., strings on a development branch) and makes translators' jobs easier. For the Gaim project, we try to freeze strings roughly one week before minor-ish releases, and longer for releases with a lot of visible string changes. The schedules are known to the regular translators (I forget the details, but I think strings freeze on Saturday for Thursday releases?), and we try to keep the translators in the loop when bizarre schedule mixups are going on. We have created a gaim-i18n mailing list for this very purpose. This also provides a place for translators to hash out issues with the strings to be translated (for example, we have had several plurality problems which had to be resolved by minor changes in program code to make plurals work in all of our supported languages). Of course, a discussion with your regular translators about their pre- ferred practices is also helpful. :-) Hope that helps, Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, On Crimes and Punishments, 1764 pgpq8NmOAuPQB.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Commit a child of 2 parents
On Sun, 2006-01-15 at 16:21 -0500, Yury Polyanskiy wrote: Hey guys! I'm rephrasing my last question. I have a tree at some state. If I want to commit it as a child to ONE revision I simply do echo $REVISION MT/revision; monotone commit. Now HOW to commit a tree as a child to TWO revisions? I.e. I want current revision to be a child of revA and revB (as if it were a merge, though I did all merging already and don't need any monotone merge assistance). You don't. That particular feature is still on the TODO list. Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Commit a child of 2 parents
In message [EMAIL PROTECTED] on Sun, 15 Jan 2006 16:21:57 -0500, Yury Polyanskiy [EMAIL PROTECTED] said: ypolyans Now HOW to commit a tree as a child to TWO revisions? I.e. I ypolyans want current revision to be a child of revA and revB (as if ypolyans it were a merge, though I did all merging already and don't ypolyans need any monotone merge assistance). You could actually do that back before the introduction of changesets, since the ancestry was defined with ancestor certs. It was dangerous to do so, though, you could get som pretty loopy results from that. These days, you would probably have to create the revision yourself, by hand, and sign it, insert it into the database along with all the necessary deltas and files, and if you're playing with 0.26pre1, you'd have to add a bunch of rosters manually, and I can't even begin to tell you how to do that. Either way, if you do that, be warned that such a procedure is VERY ERROR-PRONE, so I just wouldn't go there if I was you. So, my question to you is, why didn't you use explicit_merge, and then apply further changes on the resulting revision? That would seem sooo much simpler. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Commit a child of 2 parents
On Sun, Jan 15, 2006 at 04:21:57PM -0500, Yury Polyanskiy wrote: I'm rephrasing my last question. I have a tree at some state. If I want to commit it as a child to ONE revision I simply do echo $REVISION MT/revision; monotone commit. Now HOW to commit a tree as a child to TWO revisions? I.e. I want current revision to be a child of revA and revB (as if it were a merge, though I did all merging already and don't need any monotone merge assistance). Two further options, neither quite as elegant as we might like: - do a merge (or explicit_merge) of the revisions in question, overriding the lua merge-assistance hooks to supply the merged content for each file from a separate location where you've done your manual merging work. - commit your manually edited revision twice, once as a child of each revision, then merge those new heads. -- Dan. pgpGhH5LKpJDi.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] Add more dynamic resolution steps to tickers.
On Sun, Jan 15, 2006 at 11:56:45AM -0800, [EMAIL PROTECTED] wrote: While doing a rather large netsync, I noticed the monotone ticker switch from 99 M to the rather unhelpful 0.1 G. The following patch adds a few more steps in the kiB - MiB - GiB steps, hopefully providing a bit more resolution. Matt wrote and committed a similar patch yesterday... I guess you guys should check and compare them? -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Commit a child of 2 parents
Thanks all for replies! I was 99% sure that the solution would be to commit my merged tree as a child to revA and then call some fancy monotone db execute 'insert...' to draw an additional edge in revision graph from revB to a newly created revC. Does anyone has a short explanation why such ``drawing'' is impossible? What does it ruin? Best wishes, Yury. On Sun, 2006-01-15 at 15:35 -0800, Nathaniel Smith wrote: As others have noted, there's no sane way to do this at the moment. Which is totally lame; I'm sorry. But, now that we have rosters landed in mainline, getting this sort of interface to merging implemented is a high priority, and very doable; we have a design and everything: http://venge.net/monotone/wiki/MergeViaWorkingDir It's just a matter of someone finding the time to make it happen. (If you are/have any bored hacker friends, it's probably no more than a few days work... ;-).) -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Commit a child of 2 parents
On Sun, Jan 15, 2006 at 07:59:55PM -0500, Yury Polyanskiy wrote: Thanks all for replies! I was 99% sure that the solution would be to commit my merged tree as a child to revA and then call some fancy monotone db execute 'insert...' to draw an additional edge in revision graph from revB to a newly created revC. Does anyone has a short explanation why such ``drawing'' is impossible? What does it ruin? The signatures on the revision. The hash id of a revision is based on: - the contents of the tree - the ancestry of the revision Change the ancestry, and the revision is no longer the same one. Have two people make the same change to a revision, and the resulting revisions are the same revision. This really is a feature :) -- Dan. pgp3ZM4Jps5FL.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Commit a child of 2 parents
On Sun, Jan 15, 2006 at 07:59:55PM -0500, Yury Polyanskiy wrote: Thanks all for replies! I was 99% sure that the solution would be to commit my merged tree as a child to revA and then call some fancy monotone db execute 'insert...' to draw an additional edge in revision graph from revB to a newly created revC. Does anyone has a short explanation why such ``drawing'' is impossible? What does it ruin? Because edges are not stored separately from revs. A rev contains a list of its parents in its text; a revid is the hash of that text. So adding a new parent would require actually going and modifying the existing rev's text, and thus changing its id, which invalidates existing certs, etc. The concepts chapter of the manual hopefully covers this sort of thing: http://www.venge.net/monotone/docs/Concepts.html If anything's unclear then we'd love to hear :-). Doing all these adjustments by hand while maintaining data consistency would be very tricky. You basically end up duplicating big pieces of monotone's own code. Doing it from _inside_ the monotone code is less problematic; we can generate whatever revs we want pretty straightforwardly. If you really want an expeditious hack, you're probably best off figuring out some way to hack some sort of special purpose command into monotone. What system are you coming from, again? There is some code already to do lossless imports from git repositories (which is starting to rot, but we should fix that)); adding code to do the same from other VCSes is probably a bit more work than writing a quick hack in shell or whatever, but could also be quite valuable. -- Nathaniel -- ...All of this suggests that if we wished to find a modern-day model for British and American speech of the late eighteenth century, we could probably do no better than Yosemite Sam. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Commit a child of 2 parents
Oh, ok. I knew I was missing something obvious. Sorry for not RTFMing enough. I'm not talking about a quick hack but rather a complete lossless converter from BK to monotone. The way to do this is to either integrate infamous SourcePuller (by A.Tridgell) inside monotone. However that would probably invoke a lot of fuss from BK people. The other way is to hack SP and make it call regular monotone commands. In this latter case, of course it'd be nice if the tool worked with standard monotone releases, not some specially patched ones. So I'm just looking for a way to do this. Again thanks everyone! Yury. On Sun, 2006-01-15 at 17:29 -0800, Nathaniel Smith wrote: Because edges are not stored separately from revs. A rev contains a list of its parents in its text; a revid is the hash of that text. So adding a new parent would require actually going and modifying the existing rev's text, and thus changing its id, which invalidates existing certs, etc. The concepts chapter of the manual hopefully covers this sort of thing: http://www.venge.net/monotone/docs/Concepts.html If anything's unclear then we'd love to hear :-). Doing all these adjustments by hand while maintaining data consistency would be very tricky. You basically end up duplicating big pieces of monotone's own code. Doing it from _inside_ the monotone code is less problematic; we can generate whatever revs we want pretty straightforwardly. If you really want an expeditious hack, you're probably best off figuring out some way to hack some sort of special purpose command into monotone. What system are you coming from, again? There is some code already to do lossless imports from git repositories (which is starting to rot, but we should fix that)); adding code to do the same from other VCSes is probably a bit more work than writing a quick hack in shell or whatever, but could also be quite valuable. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Commit a child of 2 parents
On Sun, Jan 15, 2006 at 09:21:27PM -0500, Yury Polyanskiy wrote: The other way is to hack SP and make it call regular monotone commands. In this latter case, of course it'd be nice if the tool worked with standard monotone releases, not some specially patched ones. So I'm just looking for a way to do this. Ahah, now here's a very straightforward and concrete requirement that will help guide the interface design for the feature we already knew we'd probably want for something. Programs like tailor are likely to want very similar features. For now, i'd suggest you use the hooks-style approach to supply the merge with the correct file content from the equivalent BK rev. -- Dan. pgpslh0TPkod8.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Commit a child of 2 parents
On Mon, 2006-01-16 at 13:34 +1100, Daniel Carosone wrote: On Sun, Jan 15, 2006 at 09:21:27PM -0500, Yury Polyanskiy wrote: The other way is to hack SP and make it call regular monotone commands. In this latter case, of course it'd be nice if the tool worked with standard monotone releases, not some specially patched ones. So I'm just looking for a way to do this. Ahah, now here's a very straightforward and concrete requirement that will help guide the interface design for the feature we already knew we'd probably want for something. Programs like tailor are likely to want very similar features. For now, i'd suggest you use the hooks-style approach to supply the merge with the correct file content from the equivalent BK rev. Note that if monotone can merge a file without conflicts, then it doesn't call the merge hook on that file at all. Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Commit a child of 2 parents
On Sun, Jan 15, 2006 at 09:02:04PM -0600, Timothy Brownawell wrote: Note that if monotone can merge a file without conflicts, then it doesn't call the merge hook on that file at all. Yes, you'll need to set manual_merge to true. A switch to merge to imply this for all files in this commit is probably better than forcing files to have inappropriate attributes. -- Dan. pgpLuAIcKxJEa.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Commit a child of 2 parents
On Sun, Jan 15, 2006 at 10:31:13PM -0500, Yury Polyanskiy wrote: This won't handle all situations: suppose a merge revision that adds a file. I can't direct monotone to add a new file via merge hook. Correct. If you want to do this properly, I see basically two options: -- link in sourcepuller and just have monotone bk_import (or perhaps monotone sp_import). This would probably raise some fuss. LM probably would be unhappy. He hasn't actually managed to do anything about SP itself, though, and I'm not aware of any legal theory where he has the slightest leg to stand on, so, *shrug*. It doesn't seem totally insane. (Totally pragmatically speaking, even if things went pear shaped and we ended up moving the functionality into a separate tool, we would probably get a net win on publicity/sympathy etc.) -- implement merge-via-working-directory. This is a core piece of functionality for general use, not just for migration. As mentioned, this is not a large job, just needs to be done. If you do go the external program direction, it might be worthwhile to see if it can be made somewhat general; most of the code involved in importing from BK is probably the same as the code involved in importing from any other DAG-history, repo-as-branch VCS (and there are a number of these, now). -- Nathaniel -- ...All of this suggests that if we wished to find a modern-day model for British and American speech of the late eighteenth century, we could probably do no better than Yosemite Sam. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
