From nobody Tue Aug 17 18:59:25 2021 X-Original-To: ports-bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CCBA7174C804 for ; Tue, 17 Aug 2021 18:59:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gq0gx5LQqz3lYN for ; Tue, 17 Aug 2021 18:59:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9F75E22C49 for ; Tue, 17 Aug 2021 18:59:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 17HIxPTA042133 for ; Tue, 17 Aug 2021 18:59:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 17HIxPKG042132 for ports-bugs@FreeBSD.org; Tue, 17 Aug 2021 18:59:25 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: =?UTF-8?B?W0J1ZyAyNTc5MDVdIG1pc2Mvc2NoaWx5dG9vbHMgQ2hhcmFjdGVy?= =?UTF-8?B?IO+/vSBkaXNwbGF5ZWQgaW5zdGVhZCBvZiDDtg==?= Date: Tue, 17 Aug 2021 18:59:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: schily@schily.net X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not Accepted X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Ports bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-ports-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports-bugs@freebsd.org X-BeenThere: freebsd-ports-bugs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257905 --- Comment #9 from J=C3=B6rg Schilling --- GNU gettext definitely does not do do iconv() conversion for the from strin= g, it could not do that, since it cannot know the related locale for the from string. iconv() is only called in case there was a language translation from an .mo file before and if that .mo file uses GNU mime enhancements to mark the encoding of the .mo file. See: http://web.archive.org/web/20030608111824/http://www.li18nux.org/docs/pdf/L= I18NUX-2000-amd4.pdf for the Sun/GNU agreement from Y2000 as long as the upcomming POSIX standard text is not yet ready for gettext(). The problem here is that we have standards that have been defined by US peo= ple that (because they are from the US) do not suffer from the pitfalls of the insufficient UTF-8 standard. Shift JIS is a really bad encoding for the command line, since it is statef= ul. Stateful encodings are broken by design. If you however are in an UTF-8 based locale, you in contrary to your claims need to assume that the person is using UNICODE encoding and ISO8859-1 is identical to the range 0..255 of UNICODE. What p(1) does is just to implement a more intelligent handling for bytes t= hat result in an EILSEQ error. There is no "official" way for such a case and w= hat p(1) does just results in what people expect. This intelligent handling could be made part of the rendering machines that= are e.g. used by xterm... --=20 You are receiving this mail because: You are the assignee for the bug.=