Description of problem: In the disk druid screen, `Iniciar' would have been better translated as `InÃcio'. In the `About to begin installation' screen, there's an incorrect line break just before the open paren in disco(s). I don't know whether there's a blank that shouldn't be there, or if the generic line break code assumes it can break lines before parentheses, but what's there is definitely bad pt_BR. Version-Release number of selected component (if applicable): based on jeremy's screenshots posted on April 19, 2004
The word "Iniciar" has been changed to "InÃcio" in anaconda software. The "(s)" was brought back to the line stuck to the word "disco" in the help-screens software. Although fixes were done asap, I don't know if will be incorporated in FC2. If second problem persists will be necessary to review the breaking line rules. Thanks! Dave
The first problem is fixed, but the second still has the incorrect line break :-(
The breaking line rules for pt_BR should be reviewed, and according to the info I got, this might be related to pango package. We are trying to stick the plural component (s) to the word "disco" (disk in Portuguese), but the line breaking code doesn't work this way in Anaconda help screens...
Not going to change this in Pango; the Pango behavior is conformant to the relevant Unicode standard. You can insert a ZWNBSP (U+FEFF) in the translation if you want to suppress a line break. Guessing on the reassignment.
This is quite unfortunate. Saying `ele(a)' in Portuguese is the equivalent of `s/he' in English. A line break before or after the slash would be just as bad as a line break before the parenthesis. Note that there's absolutely no whitespace before `('. Must we really introduce any, even if zero-width? I can't see anything in the line breaking unicode standard that supports the statement that, in `foo(bar)', a line break between `foo' and `(bar)' is legitimate. All the standard says is that there cannot be a line break after `('. Would you point to the relevant portion of the Standard you're basing your claim on? Thanks,
(Pango will happily line-break after the slash in s/he; of course using s/he in English is dreadful style...) The rule in http://www.unicode.org/reports/tr14/ is "LB 20 Break everywhere else" So unless there is a rule forbidding it, it is a break position. Or look at table 2 - AL followed by OP is marked as _: a break opportunity. UAX allows tailoring so this rule *could* be changed in Pango... but I'm very hesitant to ad-hoc start changing rules for particular use cases. (I'll admit that this particular example has come up before; still I'm not sure I want to generalize off of two examples. Generally, if you need to use (s) in a translation, you should be beating up the package maintainer to use ngettext.)
According to Owen, pango is following the right unicode standard here