From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id AA9A21F4D7 for ; Wed, 4 May 2022 14:36:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351366AbiEDOjm (ORCPT ); Wed, 4 May 2022 10:39:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51330 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351421AbiEDOjO (ORCPT ); Wed, 4 May 2022 10:39:14 -0400 Received: from pb-sasl-trial2.pobox.com (pb-sasl-trial2.pobox.com [64.147.108.86]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 863C01F600 for ; Wed, 4 May 2022 07:35:37 -0700 (PDT) Received: from pb-sasl-trial2.pobox.com (localhost.local [127.0.0.1]) by pb-sasl-trial2.pobox.com (Postfix) with ESMTP id 2B99A2B09F; Wed, 4 May 2022 10:35:36 -0400 (EDT) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:message-id:mime-version:content-type :content-transfer-encoding; s=sasl; bh=EGFyF2SAu7idkolFS8+4bV6KP kI=; b=oMnsk7T+iX8tf5JswxEOFIEaYT+aOorEGkkfYBirva8sgg55an6rJGARE BSNg1QpIwUHyeTtVdZwGv9tmOfRZv9xyGTaRgblLRdEUKdb0ZoOa1lLIU39zgSij yASoVyMQnzXYXREVT8T3TvEWA+hODbe1Hm3YP5Ym6BzjdxGC4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=sasl; b=QVh2fVxa/nFzKoZnJTP SL6rrrMsJE27VjTfz/Rq+UvTplUnC+0r5BrIGnVcPmnoJwpdFk0ITTxwxlL9YVo1 jJWb6H6XY8W9Ik11RxBDkh3T7fwWEd71Lpldedf90WnKseVYBrv07J9V7NdQ4BQo zlFjf3gCo4K18FSwGbw632s8= Received: from pb-smtp1.nyi.icgroup.com (pb-smtp1.pobox.com [10.90.30.53]) by pb-sasl-trial2.pobox.com (Postfix) with ESMTP id 025622B09C; Wed, 4 May 2022 10:35:35 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.83.65.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 12E5011B83A; Wed, 4 May 2022 10:35:35 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: Jiang Xin Cc: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , Git List , Jiang Xin , Alexander Shopov , Jordi Mas , Matthias =?utf-8?Q?R=C3=BCster?= , Jimmy Angelakos , Christopher =?utf-8?Q?D=C3=ADaz?= , =?utf-8?Q?Jean-No=C3=ABl?= Avila , Bagas Sanjaya , Alessandro Menti , Gwan-gyeong Mun , Arusekk , Daniel Santos , Dimitriy Ryazantcev , Peter Krefting , Emir SARI , =?utf-8?B?VHLhuqduIE5n4buNYyBRdcOibg==?= , Fangyi Zhou , Yi-Jyun Pan Subject: Re: [PATCH 0/9] Incremental po/git.pot update and new l10n workflow References: <20220503132354.9567-1-worldhello.net@gmail.com> Date: Wed, 04 May 2022 07:35:34 -0700 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Pobox-Relay-ID: 756B4978-CBB7-11EC-BAB9-5E84C8D8090B-77302942!pb-smtp1.pobox.com Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Jiang Xin writes: > From: Jiang Xin > > =C3=86var and I started discussing this topic (incremental po/git.pot u= pdate > and new l10n workflow) on a GitHub issue[^1] a month ago. There are > several improvements to the l10n workflow: > > * Variable "LOCALIZED_C" is not stable, that cause the "po/git.pot" fil= e > generated by different user may have different number of entries. > This issues is fixed in patch 2/9. Allowing translators to pick a random point in the history and run the tool to generate .pot file locally creates that problem for us. It also means that various .po files would correspond to slightly different versions of the source tree. The "only the coordinator updates .pot, everybody works off of that file" was one way to ensure that you do not have to worry about these two problems. So, if you are moving to the "no .pot file committed in-tree, translators generate .pot for themselves" model, you do need to make sure you have consistent set of files to localize. So [2/9] does try to fix an issue worth solving (assuming that the new model is what i18n/l10n team members want). I am not sure what your plans are to make sure everybody works off of the same version, though. Even if you scrape the source tree for source files that may not be relevant to your build, if you do not start off of the same version, your set of sources may be a bit off compared to the other translators'. > * Generate "po/git.pot" in an incremental way, so we do not need to mun= ge > source files in-place, do not need a clean checkout, and do not need > "reset --hard". See patch 3/9. That may be a worthwhile thing to do. I have no strong opinions. > * Remove file "po/git.pot" from tree. It can be generated at runtime. > See patch 5/9, 6/9. Another reason, IIRC, why we adopted "the coordinator prepares pot" model, in addition to the stability of the source and .pot file across languages, was because we wanted to reduce the load on language team. It also may be handy to be able to view "git log -p" on the file, as long as we somehow reduce the patch noise (perhaps by stripping the line numbers that are constantly changing). Again, assuming that i18n/l10n team members are OK with this, I have no complaints. > * L10n contributors can update theire "po/XX.pot" using: > "make po-update PO_FILE=3Dpo/XX.po". See patch 7/9. > > * L10n contributors for new language can initialize "po/XX.pot" using: > "make po-init PO_FILE=3Dpo/XX.po". See patch 8/9. > > * L10n contributors can start translations at any time, even before the > l10n announcing l10n window open. We must have a new l10n workflow, > see patch 9/9. Is it truly OK for the language packs for Git 2.36 to be prepared from v2.36.0~27 for French while German are done using v2.36.0~12? Again, if there is no practical downside for doing so that worries the i18n/l10n team members, I have no real complaints, but this is the one that worries me the most, actually, in the whole thing. Thanks for working on this topic, both of you.