Hi,

I am part of a team that is reviewing the French translation of Lazarus. The French language has accented characters. These characters are not displayed in the message window of Lazarus. I think Lazarus expects UTF8 strings while the FreePascal translation file is encoded in cp850. For other languages FreePascal translations files are in UTF8, ISO-8859 or other encodings.

Can we convert the French translation from cp850 to UTF8 and send a patch ? Another solution would be to provide two versions of a file on for cp850 and antother for UTF8.

Fixed.

Mattias

Thanks for your fix Mattias.

And also because looking at your changes I noticed that there are two translation files for French in two different encodings : 'errorf.msg' and 'errorfi.msg'. So far I thought 'errorfi.msg' was a translation for the Finnish.

2015-05-07 0:34 GMT+02:00 Mattias Gaertner :

I mentioned the two files in the original response to Stephane Aulery who initiated the French translation update.

BTW, talking about this translation effort - as you might know, the release of FPC 3.0.0 is approaching (although somewhat delayed compared to the original plans by now). While the primary target of your current effort is obviously trunk, you may want to have a look at using the translated file with compiler messages as basis for updating the version available in branch fixes_3_0 once you finish your work in trunk in order to ensure the updated translation to be included in the upcoming release.

Tomas

Hello Mattias, Yann and Tomas

I did not dare to change that, but I too would like to have only the UTF-8 release.

With Frédéric Da Vitoria, we began to review the status of the translation of the FPC. We concluded that it is very difficult to maintain and not very useful because it is not implemented with ressourcestrings. We have not given up to translate, but one wonders if it will not fit first FPC for better support in the long term.

I need your opinion on this issue, given that the interweaving with the TeX manual is also very problematic.

There is also the translation of fpdoc update. I started watching. There is a resource compilation problem because the code has changed but the makefile has not been adapted taking into account the translations.

Regards,

Ok, we are going to make a translation suitable for future 3.0.

Thanks.

2015-05-07 10:58 GMT+02:00 Tomas Hajny :

"Stéphane Aulery" wrote

With Frédéric Da Vitoria, we began to review the status of the translation of the FPC. We concluded that it is very difficult to maintain and not

very

useful because it is not implemented with ressourcestrings. We have not

given

There are IMHO three reasons it is done the way it is:
- it has grown that way (probably from a time before FPC supported resourcestrings)
- the IDs, the verbosities and the messages are located in one single location avoiding a drift of these
- it is easy to generate the documentation as it's part of the same file

It might provide obstacles for translators, but it eases the work for the compiler developers and IMHO that is the main reason to keep it the way it is.

Regards,
Sven

Hello Sven,

It's not the only problem:

- It is not possible to perform FPC in accordance with the language
  passed by the environment variables;
- This part of the manual is virtually untranslatable because msgdif
  tool does not synchronize the TeX part;

- Translations are never up to date and do not compile actually.

My goal is to improve the state of the compiler and the service to users without complicating the work of developers and translators.

On this point I think the state of the compiler is not good for developers, translators and users.

The developer must edit one file at a frightful codification complicating hir life instead of a clean and structured code (including errors of descriptions). Look what it did in the Microsoft environment. It's not just the error messages but also their descriptions, ID and level, which are accessible during code execution.

This is not available but tucked only in a manual, which is almost untranslatable in the current state. In fact none of the translations is updated because it is not maintainable. I even sent a patch to fix ALMOST ALL languages because it does not even compile! So, who uses them?

Two reasonable solutions are possible to me:

- Finding a compromise that suits everyone, but it takes some work to do;

- If no one is interested, competent, available, and given that the intended audience is supposed to have enough English, we can remove these translations and mechanism complicating the compilation and clearly notify users that this part cannot be translated in the current state.

The compilation of fpdoc of ressourcestrings is also broken. So I ask myself honestly, although I would have preferred that all this is restored and translated, if the second solution is not by far the best yet.

Regards,

Regarding the discussion of the format, I would like to add the following experiences from my activities keeping the German error messages for FreePascal up to date as well as translating the documentation of another project.

The hardest work in translation is actually on the language side. Thinking about appropriate terms and also the work to make the translation consistent, using the same terms to avoid confusion. Since most of the languages are out of date, it looks like an awful lot, but it is more important to have continuous contributions than a one time shot. Once one has managed to get up to date, it is not that much work. There is about one commit per month to errore.msg and 4 checks per year are enough to really keep it up to date. Details of the format are of minor importance, then.

The Lazarus error messages are probably a different story.

My 2 cents - Michael Schindler

If the format is unimportant, why is that different please ?

Am 10.05.2015 um 12:00 schrieb

Using PO/POT files would clearly be an advantage for local use as well as web services. So, a format conversion tool from .msg files to PO/POT files and vice versa might be a solution. Solutions which need major contributions from others have a high probability to be turned down, because man power is the dominating bottle neck in open source projects. The better you can come up with a solution and maintain it by yourself, taking care of feature requests and bug reports, the better the chance for acceptance. Maybe think of tools, which you need for your work.

Michael.