Re: [RFR] man://manpages-de/wprintf.3
Hallo!
Am 14. Oktober 2012 13:53 schrieb Bernhard R. Link <brlink@debian.org>:
> * Martin Eberhard Schauer <Martin.E.Schauer@gmx.de> [121014 13:16]:
>> #. type: Plain text
>> msgid ""
>> "The B<wprintf>() family of functions is the wide-character equivalent of "
>> "the B<printf>(3) family of functions. It performs formatted output of wide "
>> "characters."
>> msgstr ""
>> "Die B<wprintf>()-Funktionenfamilie ist die Variante der B<printf>()-"
>> "Funktionenfamilie f??r ??weite?? Zeichen. Sie erzeugen eine formatierte "
>> "Ausgabe von weiten Zeichen. (Weite Zeichen werden mit mehr als einem "
>> "Byte dargestellt.)"
>
> Ich bin stark dafür alle "weiten Zeichen" wieder zu "wide characters"
> zu machen (oder zu "wchar_t", je nachdem ob das Konzept oder der
> Datentyp gemeint ist).
> Google findet gerade mal 870 Ergebnisse für "weite Zeichen"
> und darunter sind noch einige Schreibfehler von "weitere Zeichen", so
> dass ich einfach mal behaupte, dass "weite Zeichen" kein Deutsch ist.
Ich bin auch für »wide characters«.
> #. type: Plain text
> msgid ""
> "B<swprintf>() and B<vswprintf>() take a I<maxlen> argument, B<sprintf>(3) "
> "and B<vsprintf>(3) do not. (B<snprintf>(3) and B<vsnprintf>(3) take a "
> "I<maxlen> argument, but these functions do not return -1 upon buffer "
> "overflow on Linux.)"
> msgstr ""
> "B<swprintf>() und B<vswprintf>() verwenden ein Argument I<maxlen>, B<sprintf>"
> "() und B<vsprintf>() jedoch nicht. B<snprintf>() und B<vsnprint>() verwenden "
> "ebenfalls das Argument I<maxlen>, doch diese Funktionen geben unter Linux im "
> "Falle eines Pufferüberlaufs (buffer overflow) nicht -1 zurück."
Hier fehlt ein paar mal die 3:
s/B<sprintf>() und B<vsprintf>() jedoch nicht. B<snprintf>() und B<vsnprint>()/
B<sprintf>(3) und B<vsprintf>(3) jedoch nicht. B<snprintf>(3) und
B<vsnprint>(3)/
> #. type: Plain text
> msgid ""
> "If the I<format> string contains non-ASCII wide characters, the program "
> "will only work correctly if the B<LC_CTYPE> category of the current "
> "locale at run time is the same as the B<LC_CTYPE> category of the "
> "current locale at compile time. This is because the I<wchar_t> "
> "representation is platform- and locale-dependent. (The glibc represents "
> "wide characters using their Unicode (ISO-10646) code point, but other "
> "platforms don't do this. Also, the use of C99 universal character names "
> "of the form \\eunnnn does not solve this problem.) Therefore, in "
> "internationalized programs, the I<format> string should consist of ASCII "
> "wide characters only, or should be constructed at run time in an "
> "internationalized way (e.g., using B<gettext>(3) or B<iconv>(3), "
> "followed by B<mbstowcs>(3))."
> msgstr ""
> "Falls die Zeichenkette I<format> weite Zeichen enthält, die keine ASCII-"
> "Zeichen sind, wird das Programm nur dann richtig arbeiten, wenn der "
> "B<LC_CTYPE> der Locale während der Laufzeit der gleiche ist wie der "
> "B<LC_CTYPE> während des Kompilierens. Das passiert, weil der Datentyp "
> "B<wchar_t> von Plattform und Locale abhängig ist. (Die GNU Libc "
> "speichert weite Zeichen als Unicode (ISO-10646), andere Plattformen "
> "haben andere Lösungen. Auch die Verwendung von »universal character "
> "names« nach ISO C99 der Form \\eunnnn löst das Problem nicht.) Daher "
> "sollte die Zeichenkette I<format> in internationalisierten Programmen "
> "ausschließlich aus weiten ASCII-Zeichen bestehen oder während der "
> "Laufzeit konstruiert werden (z.B. durch B<gettext>(3) oder B<iconv>(3) "
> "gefolgt von einem B<mbstowcs>(3)).
»andere Plattformen haben andere Lösungen« gibt das Original mMn nicht
her, daher:
s/andere Plattformen haben andere Lösungen/
andere Plattformen tun dies nicht/
Grüße
ErikE
Reply to: