On Mon, May 18, 2020, 3:58 PM thraex <thr...@numericable.fr> wrote: > > > On 18.05.2020 15:17, Jerome Shidel wrote: > > > First, http://freedoslocal.sourceforge.net is no longer maintained. > > Indeed, that's a resource I miss sorely as a translator :( > > > Occasionally, individuals have sent me translations for packages other > > than the ones I develop. With no good place to send them at present, > > I just started to funnel all translations into a new Github project > > at https://github.com/shidel/fd-nls > > > > At present, I’m thinking of it as a new temporary home for all of them. > ...
I understand both sides, from a translator perspective, having a single location to check for and submit updates to is both useful (avoids wasting time & effort to find who & where) and convenient (only 1 instead of many places to find and submit updates). From a project perspective, we want to encourage translations, so the easier this is then the better. However, the reality is that a FreeDOS distribution is like a Linux distribution, a collection of separate programs grouped together and installed as though it were a singular piece of software. Originally there were quite a few developers and each piece was maintained by different people; not necessarily the case today. I still like having the translation with the program and maintained along with it, but I want to encourage translations. My concern is having multiple places to submit a translation for the same program will result in wasted or duplicate effort. Pulling translations out and into their own project is going to make building (compiling) more complex, now you need to download and extract translations from a separate project sometimes even before building, depending on what translation mechanism is used. Personally I would like to split the process. Have a central repository for translations* that is easy for developers to add new strings to, easy for translators to see what has changed/added and to add translations for, that is not tied to how the programs use the strings (I'm sure there are common standard formats in use that can be easier for translations and easy enough to convert to program specific format). The FreeDOS site should prominently point to this location, be it on Sourceforge, a GitHub repository, or a third party translation site hosted by whoever, ... Everyone would know where to send updates to regardless of which program and developers can periodically, such as when making a new release, download latest translations, convert to appropriate format and include the conversions into their build process. No risk of lost translations, duplicate work, or confusion. So my questions: What is the best format for translators? utf8 po/pot file, code page specific catgets format (i.e. current format for many of the programs), some json, csv, or xml format, ??? Where should these translations be stored including how to update and download? The fd-nls GitHub page, a new GitHub page, try and revive the fd-local Sourceforge site, try and join another open source projects translation site, ??? Can we agree to use the above site and format for sharing or is this going to be some do and most don't so eventually stopped being updated as well? I am willing to convert all the current programs that are part of FDOS GitHub site that lack upstream maintainers to do this. That is, submit a source set of messages and current translations of appropriate format to shared site and then download and convert back for releases. Current translations would be deleted from FDOS repositories with updated instructions for where to send/get translations and how to build (downloading and converting needs to be an automatic part of compiling). Sorry for such a long message. Please reply. If there is not much discussion or consensus, then I will likely just create a new repository under FDOS with latest translations and update the other repositories to use it as described. Format undecided, but with tools to convert to po and program format. Maybe freedos-local is what I want and I just didn't contribute to it's success. I appreciated it. I think the key is to remove translations from program sources and instead combine when building/packaging for release but avoiding duplicate public locations to get/submit translations to. For catgets based programs, the release build need not include translations at all, a complete set* for a given translation can be its own package/download. *Note that I am mostly concerned about the core (base+) programs, but it would be nice if it worked out for other included programs as well. Jeremy
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel