Re: [Quilt-dev] translations issues

[Andreas Gruenbacher]

On Monday 12 July 2004 05:46, Martin Quinson wrote:
> Ok, the french translation is synced to EN again. Some reflexions I had
> during the process:
>
> #: ../quilt/edit.in:16
> msgid ""
> "\n"
> "Edit the specified file(s) in $EDITOR after adding it (them) to the\n"
> "topmost patch.\n"
>
> Your intention was to get $EDITOR expended (in which case it should be
> changed to printf) or to protect it (in which case I doubt it wanna work)?
>
> same in
> #: ../scripts/rpatch.in:22
> msgid "Usage: $0 [-fRq] patchname\\n"

Yes, a few expansions are still left. Feel free to fix them ;)

> I also consider that all those "\\n" in the po files are nasty. I'd prefer
> constructions such as
>         printf $"Usage: quilt edit file ...""\n"
> if possible.

Yuck -- I don't like making the code harder to read just because of 
translations. A simple function like this would do, but I'm not excited about 
introducing more abstractions: this would slow things down, and make toe code 
more awkward to understand...

        printfl() {
                local fmt=$1
                shift
                printf "$fmt"$'\n' "$@"
        }

> Afterward, we will be able to set the c-format flag on 
> translations to make sure that translation and original have the same
> amount of %s and such.

Good idea. Where in the pot file does that go? Can you do it?

> Of course, it does not apply to multilines strings 
> (where '\n' is actually '
> ').
>
> We may also switch to gettext(1) instead of the $"" bashism. I'm really not
> convinced there is a need, but gettext maintainer simply hates $"". See
>  info gettext bash

As if using gettext(1) would solve any of the problems that $"" has -- I'm 
quite fine with $"".

> #: ../quilt/pop.in:25
> #, fuzzy
> msgid ""
> "\n"
> "Remove patch(es) from the series file.  Without options, the topmost\n"
> "patch is removed.  When a number is specified, remove the specified\n"
> "number of patches.  When a patch name is specified, remove all patches\n"
> "up to and including the specified patch.  Patch names may include the\n"
> "patches/ prefix, which means that filename completion can be used.\n"
>
> This is useless provided that one source /etc/bash_completion.d/quilt,
> which should be usable on non-debian box when I commit the last changes of
> Joe. Should we remove that sentence? We may leave the functionnality in
> place, but it seems redundent to me.

We should indeed keep the functionality. There are people who are not using 
bash as their shell; also many bash users don't use the completions.

> And it's broken when not in root dir. 

Needs fixing, then. For well-formed, relative patch names it's quite easy. (A 
more complete solution would be to check whether a directory component of the 
patch name takes us to $QUILT_PATCHES.)

Cheers,
-- 
Andreas Gruenbacher <address@hidden>
SUSE Labs, SUSE LINUX AG