(no problem for the inconvenience...but I wanted to remind all D-I
contributors that translatable text should preferrably be discussed
before being introduced. Indeed, I briefly saw yoru work in your
branch and I was considering to pop up and ask whether this is meant
to be injected in the trunk...but you've been faster than me...:-)))
> When a list of volume groups are presented to the user, some stats on
> each volume group is sometimes included, including the number of
> physical volumes which the volume group uses. For example:
>
> Please choose a volume group to reduce:
>
> mainvg (825MB - 2 PVs)
> secondvg (912MB - 4 PVs)
Hmmmm, reconstructed sentence. I feared it.
The problem with such sentence is that they're sometimed impossible to
properly translate because of the various languages structures. Here,
the problem is not that high, because we don't have a real "sentence".
However, I suggest removing the "s", for two reasons:
-acronyms usually don't use plural marks
-it assumes the English way to mark plural....which may be incorrect
for some languages (different forms for different numbers). As the
po-debconf stuff doesn't handle gettext Plural Forms, we'd better
avoid such corner cases)
So, we'd better use "PV" alone, and explain translators that they
should use the acronym for "Physical Volume" in their language (e.g. I
would use "VP" for "Volume Physique", for French).)
>
>
> >Template: partman-lvm/text/lvdelete_invg
> >Type: text
> >_Description: in VG
> >
> >(seems to be a part of a reconstructed sentence. Is it?)
>
> Similar to the above, it's used to describe which volume group a logical
> volume belongs to. For example:
>
> Please choose a logical volume to delete:
>
> rootlv (825MB - in VG mainvg)
> swaplv (412MB - in VG secondvg)
That one is harder because we're closer to a reconstructed
sentence. For instance, some languages might want to use the volume
group name *between* "in" and "VG".
I suggest you use a variable for the volume group name and make this
translatable:
"in VG ${VG}"
then we'll add a comment to give more context to translators.
> >I also have concerns for the wording: "Physical Volume" and "Logical
> >Volume" are capitalized at some places which is typographically
> >incorrect. I see no reason for an exception here.
>
> I have no objections to lower-casing them.
I already did it..:-)
> >Untranslatable "Choices".
>
> The choices are in the partman-lvm/menu/* templates, they should be
> translatable?
Yes, they are, but the variable shouldn't be translatable itself.
>
> >Incorrect enumeration style
>
> Not sure what you mean...
You use "asterisks":
* foo
* bar
In other place, and more generally in debconf templates, I recommend
hyphens:
- foo
- bar
Indeed, here, as we may have size constraints, I even recomment not
using any bullets at all. Which is what I commited.
> Is space at such a premium on the main menu screen? The summary is
> displayed at the top and then the menu choices (which is usually 3 - 5
> different actions). For me it all fits without any problems on a 80x25
> screen. Even if translated texts are longer, they should have room?
You can't really know. Our German friends tend to be quite
verbose..:-). So any saved character can be worth it in such
conditions.
Given that this summary is not exactly an enumeration, I prefer we
just hard-format it...without bullets.
Attachment:
signature.asc
Description: Digital signature