Translating texts even for a small application can be very complex. A simple translation of single words can fail quite dramatically.
As an example consider the English word "Record". this can mean several things, it could be an old vinyl 'record' a 'record' in a database or even start to 'record' music or conversation each meaning has to have a context. At this moment the Language Tool takes no account of the context of a word used in the programme, it is planned for a future release.
Other considerations are that not all text in a programme needs to be or should be translated. A good example of these are SQL statements embedded in the programme. These are allways English and translating them will break any programme using them. With databases in mind the programmer will need to think about field names etc in any database. A field name of "City" referred to in the programme could easily be translated and after the translation any reference such as DatabaseColumnIndex() will also be broken. I recommend that when designing a database for the applications use that all field names etc are prefixed with a small code such as "CD_" so when the tool is run they will be instantly recognisable and assigned to be ignored.
Finaly planning. How and when will the translations be applied to the programme? If the translations will be assigned only at application start then the user will need to restart the programme after selecting a new language. Some early planning can allow the user to select a new language at any time and have that applied immediatly. Simply gathering all texts into a single procedure at the start of a window definition in the programme will allow that procedure to be called to apply translated text at any time without disturbing the application state.