Hi I’m new here. I worked recently on decoding the functions of the Märklin Interface 6050/6051 and 6023/6223 and wanted to helf to add support for it to some open souce softwares. But first i need to fully understand the software. Then I saw that help in Translation is an thouth that I could help. I speak Polish and German fluently and would like to help with POEditor to refine the German translation and help to create a Polish one.
Many thanks for checking and completing the German translation! I’ve updated the language files, see commit, test build is available @ Traintastic development builds
Once the Polish translation is (almost) complete, I’ll add it.
I’m currently working on the final bits for the Traintastic v0.3 “Copenhagen” release, try to have it ready before Christmas . It would be nice if we can ship it with a 100% translation of all languages
I have starting to translate the manual. I’ve copied the ‘en’ folder to ‘de’ and will now edit every file. It’s currently on the branch ‘cbus’, but I think it’s okay, if I made a pull request, when I am ready with the translation?
Greetings, Tom
The ordered hardware has delivery delay, so I must do some other things
That is awesome!, the English manual is far from complete so you will run into stuff that is missing (additions to English are also welcome). There is no proper build support yet for other languages, but if you open a draft PR, I can add it to the PR.
Making the changes on the cbus branch is not ideal, best is to create a new branch from master, e.g. manual-de then it can be independently merged without combining it with cbus support. (Common practice is to use one branch per feature.)
if I think about it, I would prefer a branch for all documentation purposes. Switching the branches for en and de (and other languages) during the writing is not so productive What do you mean?
@reinder / @DL7BJ
Im more than happy to do some proof-reading if it helps.
English and Dutch would be my primary languages.
German reading i should be fine with too [ admittedly fairly rusty after not using it for years||decade?? ]
Frysian would not be on my radar → i can understand spoken frysian but can not speak or write it. But google/oersethelp might become my friend
POEditor would probably be easiest, but if i have to i can work with gh/json
At the moment most help/input is needed for the manual content, many things are still undocumented. The most important section currently is Getting Started, I’ve written it, but I’m also the software author so I’m very biased.
You can build the manual locally using build.py in the manual folder. You need to install the Python packages from requirement.txt, common practice is to use a Python venv. Do you have (some) Python experience?
My vision is to describe the interface in the Interface configuration in a generic sense, (allmost) no hardware specific details. Hardware specific details should go into the Appendix → Supported command stations section. My Idea is to add subpages there for different command stations, same as is done in the smart booster section.
I prefer to have the manual as hardware independent as possible, else many generic information is cluttered with all kind of hardware details, this might confuse people. Therefor hardware specific details/quirks should be in the appendix, the people can read their the info which specifically applies to the command station they own.
I had already started translating into German, and during that process I came up with the idea of writing documentation for Traintastic,CBUS/VLCB, and the hardware, my own and that from MERG. This is very specialized, but I need it for my own use; I can’t remember everything anymore However, I prefer LaTeX for this kind of technical documentation, but I think pandoc can generate markdown from tex.
@DL7BJ Happy to have a look to make sure German and English line up if it helps . More eyes == greater chance of catching conflicts/differences
If useful im happy to translate stuff if that takes stuff out of your hands
@reinder Im fine with python/venv. Good choice to separate generic vs specific.