From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,PP_MIME_FAKE_ASCII_TEXT, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26849 invoked from network); 8 Jun 2023 11:02:41 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 8 Jun 2023 11:02:41 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1686222161; b=jbeg0dHhsjZBcOy1ODqPvBEsrBY48Z0SGSPxfvJuJU1BKla/tMBRoAog+GYmxbIIHX2L8fSPBH TT0z7V7tcXylQ4iljNhZB72lv+LdMXe3jc7hor6laCVeT2tOUvCHeXrtlMxLEOejGAkPqVQ8E3 r37kZhfeW8Db/I6XWvefmLBUMvEEUh/Y0pM8Bz/DuuzOhpDjY0lnKWvGliR+kMRjoYW8QP2oou zwohPOBdqnO9JB8UkZLdKgxkiMl/p20cAOAHUukgEl0LJb+YwyGKP6lCsgrD9rtyUZ3W0trigK /gz2LBl0moJoClITf18HQsrTiSwB4E/18Ji9RZT2wKwP7g==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (maila2.tigertech.net) smtp.remote-ip=208.80.4.152; dkim=pass header.d=blaatscaahp.org header.s=2.tigertech header.a=rsa-sha256; dmarc=pass header.from=blaatscaahp.org; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1686222161; bh=sCjHiQ9osHfIvkHR3rih0yzHrQ9zZnNabVgQ8tzf5Rk=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:References:In-Reply-To:Subject:Cc:To:From:Date:Message-ID: DKIM-Signature:DKIM-Signature; b=EFZZB4biJGi/l4z+GCeM/Ac1GEE40CjFZ2o1GeyXEaPfwigvNRxxl1hOgKxtQGDGUJe3Sbei4Q qJwcrtfxTD6z28D6AdDSTGOcsmgBTEZt8vJ5QpcgAP6NJR/3XJXoTreFbWGP7797pxWSDsrKkG pxWo+cUgov966q95e1a3iSujT2Lgvfq1W59957/wYDn6ZQMelf8JVhnrbLq29LpVgXmX3CWhKQ IimIhbWICIFN/0sf+1BUil+nf9+Ic4pNjVqKJGUIVUNtwb1jbrr43gvcKCt1RCMKVd00BIknSi dU/eMdMvL3zKKDkZ3QmUpTpGOZXRmOt3CpArNOQhn0UC9w==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:References:In-Reply-To:Subject:Cc:To: From:Date:Message-ID:Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=Vi297WkRnwjlt+2H0wnHqdSSG009t0Ft4L2aendTIdg=; b=MiVe5j7t6sHNpWkW2SFREef8EY 6iOP5JSpW3jO1VK1XxaUIYoiB8DbtF7N9ZOXrbi6zsrKA5Itg++SZWB6xyeC32ustKqZgnMxpXIL1 sxRTmAywJj90As/9h4S0UYH3BVU88gIseSop3geWCc844e5c7m8ElYKPtrwYqXm/askXv15isRPEy L1b1vTruzvUkaaSC62PtFO7OWK0vw0r73XN/oxyiqbUU84Q96ighJc7gWccb69Dcmimht+Dwnrtxw 8/1ACRdBM9FWZb75nGhGdHX9W704osKhPpu0TYLnp4Imi6QMoFwV5NRNY2xS/e+6UT1W+qNvezM37 Ue96cnkg==; Received: by zero.zsh.org with local id 1q7DPd-000LsT-AC; Thu, 08 Jun 2023 11:02:41 +0000 Authentication-Results: zsh.org; iprev=pass (maila2.tigertech.net) smtp.remote-ip=208.80.4.152; dkim=pass header.d=blaatscaahp.org header.s=2.tigertech header.a=rsa-sha256; dmarc=pass header.from=blaatscaahp.org; arc=none Received: from maila2.tigertech.net ([208.80.4.152]:56191) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1q7DPK-000LZA-Ep; Thu, 08 Jun 2023 11:02:24 +0000 Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4QcLrq5gmZz6GvhH; Thu, 8 Jun 2023 04:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blaatscaahp.org; s=2.tigertech; t=1686222139; bh=Vi297WkRnwjlt+2H0wnHqdSSG009t0Ft4L2aendTIdg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=OPOmCgC97NTF7kPBY9k2C8E9qLaGDOJ0iBprkCCnKwvlA5F2JKSqMUh7LItLe1FXM D41hGX+unRmGNG3kU/Yy3zriSHK5zT3PH1hj+b2TnZR5a4HE2zrczN4e8rXFd8ssze 90sk2/62BKf0K5lK0epOnzjuyMdw9Lu8SCnGEQmg= X-Quarantine-ID: <24-5UqlYdqET> X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from localhost (cst-prg-74-11.cust.vodafone.cz [46.135.74.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4QcLrp4k7jz6GvhJ; Thu, 8 Jun 2023 04:02:17 -0700 (PDT) Received: by thinkcrap.localdomain (Postfix, from userid 1001) id 6588235546A; Thu, 8 Jun 2023 11:02:12 +0000 (UTC) Message-ID: Date: Thu, 08 Jun 2023 10:44:12 +0000 (UTC) From: zeurkous@blaatscaahp.org To: Oliver Kiddle Cc: Bart Schaefer , Peter Stephenson , zsh-workers@zsh.org, Agron Selimaj Subject: RE: Re: Is there any desire to support languages other than English in zsh? In-Reply-To: <9793-1686219221.001671@BXZw.xfyB.dZzR> References: <964331068.5072751.1686066885601@mail.virginmedia.com> <9793-1686219221.001671@BXZw.xfyB.dZzR> User-Agent: 822_dng. X-Seq: 51854 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: On Thu, 08 Jun 2023 12:13:41 +0200, Oliver Kiddle wrote: > Agron Selimaj wrote: >> What if we take the long path by starting small? >> >> Let me add gettext support, and we don't have to use it everywhere from day >> one. > > This seems like a sensible approach to me. Adding gettext(), is mostly > just about identifying information messages so doesn't need extensive > knowledge of the existing internals. A --disable-nls configure option > can be added to satisfy anyone who is concerned about the implied bloat. The bloat is also on the source level. This can make maintaining code {,significantly }harder. > There may be border-line cases such as the prompts for history searching > ("bck-i-search:") where we may want configurability at a zsh associative > array level like Peter was suggesting. But that can perhaps come later. Given the already relatively self-contained nature of zsh, me'd argue for the associative array approach, zeroth. >> This means, I'll make this text be extractable to generate *.POT files and then >> we can use all kinds of tools and websites to do the actual translation. > > I'm vaguely aware that websites exist to allow non-technical people to > contribute translations. Do you know of any good ones? It would be best > if we have an individual or small team that keep that in step with the > git sources going forward so that people interested in the C internals > need not be too concerned with the translations. Dear $DEITY, please let's not let people contribute translations unchecked at all, and on top of that, "non-technical" people tend to get "technical" things wrong. Very wrong. Misleading and incorrect translations will be a fact of life. >> This is definitely not something we would want to dive into until >> after whatever the next zsh release is, is done. > > I don't think its especially helpful to put off any particular efforts > on that basis. If the release manager feels that some recent work is > half-baked, git makes it very easy to create a release branch off from > some earlier point and backout or cherry-pick changes. Or something new > can be diverted into a temporary feature branch. Currently, I'm not > aware of any vague plans around timing for whatever the next release > will be but that would be a separate discussion. While seeming simple initially, these kind of changes have the potential to become quite invasive. Perhaps deferring any such work is best, but a feature branch could work. > | An incomplete, underdesigned "feature" upsets people more than a lack of > | such, IME. Besides, sprinkling gettext calls around just leads to more > | bloat, and more importantly, is inconsistent with the existing design > > I don't see that as leaving the feature "underdesigned". It'd be fully > designed, That sounds like a pipe dream for now. Working w/ natlangs is notoriously difficult, even for native speakers (most of them haven't quite mastered their mother tongue{,s}, either). Giving the amount of messages in zsh, we'll be finding grammar problems forever. And me'll hazard the prediction that some of them just cannot be fixed without compromising the exact meaning (mehopes medoesn't have to elaborate on how very important exact meanings are in computing). > it is just the coverage of strings that may be incomplete > ("from day one"). Our coverage of the world's many languages can never be > complete. Yes. And that leads to no end of work, while we're already struggling to manage the many features we have (and especially their interactions). We'd be inducing expectations that we cannot hope to ever fulfill. > It'd probably be best to have decent coverage of strings and > at least a few common languages covered before it makes it to a release. > gettext() calls can be substituted by a macro that does essentially > nothing so no bloat is forced on binary builds. A macro hides bloat; it does not remove it. --zeurkous. -- Friggin' Machines!