From: "Lewis" Received: from [192.168.100.201] (account lgrosenthal@2rosenthals.com HELO [192.168.100.23]) by 2rosenthals.com (CommuniGate Pro SMTP 5.4.10) with ESMTPSA id 911425 for cwmm-dev@2rosenthals.com; Wed, 22 Jul 2020 01:07:01 -0400 Subject: Re: [cwmm-dev] Proposed sync merge of TW localization into v2.9 branch To: CWMM Developers Mailing List References: Message-ID: <5F17C971.60906@2rosenthals.com> Date: Wed, 22 Jul 2020 01:06:57 -0400 User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:38.0) Gecko/20100101 Firefox/38.0 SeaMonkey/2.35 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 07/21/20 11:05 pm, Dave Yeo wrote: > On 07/21/20 10:39 AM, Lewis wrote: >> Are there any objections to me merging the /tw/ localizations from trunk >> into the v2.9 branch? > > Not here. Guess the makefiles will need updating at some point. > Speaking of which... Are there enough loose makefiles floating around the repo? Egad. It seems that every language has a makefile for something which could have been done with a single file a level or two above which was not NLV-specific. Oh, well. It's a process. >> >> Further to this, it appears that the translator also worked on >> mediafolder/prog_tutorial, creating mediafolder/prog_tutorial_tw (this >> is the only localization of this material). Assuming we merge this as >> well, is this the naming convention we want to use for these, or would: >> >> mediafolder/prog_tutorial/xx/ >> >> be better? I would do the rename after the merge, leaving the existing >> trunk unsullied. > > Either is fine here. > Okay. Thanks. Steve, any comment before I dive into this? In general, we have a mix of: /xx/ /xx/filename_xx.ext /xx/filenamennn.ext and the ecs-branded files for each. We should settle on a convention at some point. It seems oddly redundant to need: classes/res/nl/audioconv_nl.dlg I mean, if it's in the /nl directory, why add _nl to the filename? Again, it's a process, I guess. We should move slowly and get a build going first, before adding more makefile changes. -- Lewis