Hi Jeremy and everybody,
I would only suggest any form of automated infrastructure, central storage, distribution or conversion of translations if you expect translations to happen frequently, which I do not, or if you like tinkering with such infrastructures :-) In the normal situation, I would ask myself: Which apps have translation support? Which are sufficiently high profile to be worth updating? Which of them are still maintained? Those which are not can be recompiled and published by somebody else, maybe even in a centralized way. For those which are, you can send the new translations to the maintainer and get back fresh packages. I understand that this takes effort for translators, who will also not know which maintainers are still active. LSM HTML on freedos.org/software could probably indicate that, as well as giving hints on whether the "original" site still is active or whether newer versions only exist on our ibiblio copy. Of course it would also be nice to have a central point for the translators: Somebody would have to collect all translatable code bits from the individual packages (NOT normalizing it into single file formats if you ask me) and put them in a repositore. When a translator submits changes, the repository maintainer could then distribute the changes back to the package maintainers or, if no maintainer is active, make fresh packages themselves for ibiblio. That would require a translation coordinator to exist and feel like doing this. Also, there is a risk that others have been doing the same, leading to duplicate work. Talk to the others and organize a cooperation or, if retired, handoverin that case. I would not worry about causing too many version number changes because as said, translation updates are rare and very unlikely to collide in-flight when several people update their languages. After all, this is a very calm little OS compared to Linux :-) >>> at https://github.com/shidel/fd-nls > The fd-nls GitHub page, a new GitHub page, try and revive the fd-local > Sourceforge site, try and join another open source projects... > 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 I disagree. FreeDOS is too heterogenous for that and I would not change that for fun. You can make a collection of build scripts to more easily update packages in their current form if you like. Also, splitting packages into modules on different hosts has caused trouble with FreeCOM and SUPPL lib, so even though in THEORY other packages might share source bits, I rather have everything needed for one package in the package itself. Same for the EDIT TUI lib. > catgets based ... the release build need not include translations > at all, a complete set* for a given translation can be its own > package/download. I rather want ALL translations to be included with the package, it is more intuitive for DOS to not have to install separate NLS stuff. Regards, Eric PS: Who ran freedoslocal.sf.net and what happened to it? _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
