Re: [MiNT] Translation

[Paul Wratt <paul.wratt@gmail.com>]

On Wed, Dec 9, 2009 at 10:09 AM, Christos Tziotzis <ctziotzis@gmail.com> wrote:
>
>
> 2009/12/8 Jo Even Skarstein <joska@online.no>
>>
>> Gerhard Stoll skreiv:
>>>>
>>>> Another thought for this approach was a tool to translate RSC files
>>>> directly and save a new copy.
>>>
>>> Use ResourceMaster 3.65
>>
>> I think he mean an automated tool.
>>
>> Jo Even
>>
yeah, an automated command line tool (or similar)

>>
>
>
> There are some ways one could do that. The program rsc_tran should help.
> Also there are a couple of translator programs that can translate text
> files.
>
> http://users.otenet.gr/~papval/
>
> From my experience, I wouldn't suggest using it for something complicated as
> teradesk (I did a greek translation but stopped due to lack of knowledge and
> interest from other people) but I imagine it should be easier for other
> programs.
Are you interested in finishing the translation for TeraDesk

>
> I think a program called xlator was used to translate from german to
> english...?
>
yes it was, and I thing there is a freeware version of it floating
around (but dont quote me on that)

The translator tools able to do it dynamically, are always going to
give better results if the the translations come from a "dedicated"
file, but something similar to what Peter says, whould be possible,
certain generic terms "Open", "Close" etc.

What I would not do is place this load on run time, from within XaAES,
just because per RSC file it only needs to be done once, and the
results should be written to a new copy of the RSC. It can still be
dynamic, and initiated from the AES, but if a text file was generated
from the RSC, patched (with only simple word replacements), then an
new RSC compiled, the text file could then be edited more fully, and
the process updated to give a better RSC result.

This would also allow for the collection at a "language repo". This
was the approach was how I was to supply language updates  with
AFROS-update, except that instead of XaAES doing it dynamically (as
needed), it would be a one time, system wide replace ment, for CICONS
also (including icon names).

Obviously AFROS-update deals with a closed set of programs so it is
not as huge of a task as it first sounds. XaAES, TeraDesk, Taskbar,
HyperView, and only a limited set of apps. This means anything that is
not accessible for source changes (because of internal language)
could/would be supplied as a "hacked" binary, tricky but doable.

to help aid the "creation" of these things, requires a certain set of
"defaults". I already have scripts that can generate a 1.16 and 1.17
config files for both MiNT and XaAES, and they compile the CNF in such
a way that external includes are used to manage the parts that can
(and will) change for various reasons. Like Auto folder programs, AES
init, XaAES widgets, AES setting that can be tweaked, Desktop etc.
What the AES script can do, is generate either a XAAES.CNF, or a
MYAES.CNF from the same base set of files

The idea of using scripts is as a fallback for any future Config apps
(I have one in mind). One can change themes via an option, and (with
both AES atm) copying of texture folders can be done, then either
reboot, or (preferably) restart the AES (or something similar).

With this technique, I can also control MiNT boot versions, and on
ARAnyM, EmuTOS versions, from within the file system that MiNT/TOS
uses. Command line directory ordering, and file renaming can be used
of standard TOS boot processes. This allows you a facility similar to
linux "reboot _this_ OS or Kernel Configuration". Leading to such
commands as "rebootas 115 myaes ecogreen", and therefore front ends..

I have already collect alot of AFROS related language files, including
RSC's, HYP's, DOC's, BUB's, SIC's, CICONS, other help file types, for
EN, DE, FR, and NL.. I know there to be some CZ and PO as well and
maybe some IT and ES, but theseare not so easy to come by atm..

Cheers..

Paul