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,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25101 invoked from network); 8 Jun 2023 10:14:00 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 8 Jun 2023 10:14:00 -0000 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:Message-ID:Date: Content-Transfer-Encoding:Content-ID:Content-Type:MIME-Version:Subject:To: References:From:In-reply-to:cc:Reply-To:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=apRPSWGhsjA8O1XSAAI3Y0MrH9DIgpxLARCLR1b1jkk=; b=Jw7x8BG9ElFLvUL81+D4K2B1Do cD7WJWtlwAkdOEpxckSLx0hitfUQuB6vCrYXJXS6MJJbIGqFZJcz6Snh7SrSemxkE9R1MHEMGuf/i fIkZz7yg3lYnG8nP1Z6NAtyT/I7ZVnbaRlRSeG0uwViB3HTtlHLLwPZKfZGH5k7fQ/ull5xu2OoJ0 ObWMgrBBBgqH9eoGDqfThkyANF1JzH7pQqAGv/vuOuxp0YFBen3CWS+19ES5wcUyTjrmb7o0RuUtD YOnYHEoZJPBjQOPsmZqLKST0s8abnhz3EdSWhrnF66NbZaSV2smdJkLOxitBcMJpXVfcHDLxGqYue FQZWI1Fg==; Received: by zero.zsh.org with local id 1q7CeV-000JWX-Do; Thu, 08 Jun 2023 10:13:59 +0000 Received: by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1q7CeF-000JCk-5f; Thu, 08 Jun 2023 10:13:43 +0000 Received: from [192.168.178.21] (helo=hydra) by mail.kiddle.eu with esmtp(Exim 4.95) (envelope-from ) id 1q7CeD-0002Xy-2N; Thu, 08 Jun 2023 12:13:41 +0200 cc: Bart Schaefer , Peter Stephenson , zsh-workers@zsh.org In-reply-to: From: Oliver Kiddle References: <964331068.5072751.1686066885601@mail.virginmedia.com> To: Agron Selimaj Subject: Re: Is there any desire to support languages other than English in zsh? MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <9792.1686219220.1@hydra> Content-Transfer-Encoding: 8bit Date: Thu, 08 Jun 2023 12:13:41 +0200 Message-ID: <9793-1686219221.001671@BXZw.xfyB.dZzR> X-Seq: 51852 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: 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. 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. > 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. > On Wed, Jun 7, 2023 at 10:56 PM Bart Schaefer <[1]schaefer@brasslantern.com> > wrote: > > Having previously overseen the gettext-ification of a piece of > software of similar original vintage and complexity, I would say that > supporting the databases is often the least of the issues.  Sentence > structure varies, which requires converting catenated substrings into > snprintf formats or sets of alternatives; pluralization may differ, > requiring 0 / 1 / >1 conditionals even with gettext intervention; etc. Isn't that what ngettext() is for? The domains - dgettext() - looks like something we might need to be concerned with. Should modules use a different domain? > Also, because of the pervasive changes required, we found it necessary > to merge all outstanding code changes and call a halt to other > development until the "l10n" pass was complete, or we couldn't track > deltas accurately (though we were stuck with CVS for version control > at the time). I can understand that having been necessary. It may matter less in zsh if the pass is incomplete. And as software goes we probably have relatively few user-readable strings (unless you count completion which I assume is firmly out of scope for this). > 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. zeurkous@blaatscaahp.org wrote: | > Let me add gettext support, and we don't have to use it everywhere from day | > one. | 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, 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. 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. Oliver