[QUOTE=Prime95;584929]
Prime95/mprime "gave up" on localization as all text messages are hard-wired into the code. Fixed messages would not be terribly hard to place in a central location, but printf messages are much tougher. For example, "roundoff error of %g at iteration %d, rolling back to last save file %s". When localized, the %g, %d, and %s replacements might need to be in a different order.[/QUOTE]

I've tried to translate (a part of) the source code into Chinese yesterday. However, when I started compilation on VS2019, I saw the error "hwloc.h no such file or directory," repeated dozens of times. Is there a file shortage in Prime95 source code package?

also the "#pragma code_page" command is very difficult to adjust. I'm supposed to change it to 936 for a Chinese version, but even more errors and warnings occurred.

hwloc.h is here: [url]https://www.open-mpi.org/software/hwloc/v2.4/[/url]

[QUOTE=Prime95;584929]For example, "roundoff error of %g at iteration %d, rolling back to last save file %s". When localized, the %g, %d, and %s replacements might need to be in a different order.[/QUOTE]Make it independent sentences.

English: "Roundoff error of %g. At iteration %d. Rolling back to last save file %s".
Nonglish: "Erreur %g du roundoff. Iteracion du %d. Saviour phile de %s du previour".

Something that occurs to me is English synonyms might translate differently in different languages or different phrases.
at iteration becomes [B]bei[/B] iteration,
by iteration (durch Iteration),
to iteration becomes zur iteration in German.
upon iteration ([B]bei[/B] iteration)
after iteration (nach der Iteration)
Through iteration (durch Iteration)
on iteration (auf iteration)

But "upon" by itself became "auf".
(Again, google translate. My German is a dim memory.)

[QUOTE=retina;584935]
English: "Roundoff error of %g. At iteration %d. Rolling back to last save file %s".[/QUOTE]
Chinese: "在第%d轮迭代出现%g的取整误差，回退到上一存储文件%s。" Notice that the order of %g and %d has been adjusted.

[QUOTE=kriesel;584930][…] I make no claims of correctness of the Google translate results, and don't understand the seemingly random capitalization it included. […][/QUOTE]

It seems fine. In this case, all nouns are capitalized, which is correct.

[QUOTE=kriesel;584936]Something that occurs to me is English synonyms might translate differently in different languages or different phrases. […][/QUOTE]

Yes, and in general, prepositions might be translated differently according to the noun or verb used. For example "discriminate against" will turn to "diskriminieren", the "against" part (literally "gegen") has to be omitted.

It occurs to me that it would be much more productive to start with translating the readme/undoc/whatsnew files as, presumably, these would be the initial "go to" for users to get help.

BTW, localizing the messages on the program side can have the negative effect of making error reporting (screenshots, etc.) incomprehensible.

:two cents:

[QUOTE=axn;584954]It occurs to me that it would be much more productive to start with translating the readme/undoc/whatsnew files as, presumably, these would be the initial "go to" for users to get help.

BTW, localizing the messages on the program side can have the negative effect of making error reporting (screenshots, etc.) incomprehensible.

:two cents:[/QUOTE]
+1

[QUOTE=axn;584954]BTW, localizing the messages on the program side can have the negative effect of making error reporting (screenshots, etc.) incomprehensible.[/QUOTE]

This can be handled by outputting the error messages twice if they are localized - once in the original English (or whatever original language is appropriate for the developer) for whoever is supporting/maintaining the code, and then in the localized language. This probably should be done with everything going to the log files, not just the errors, or have two log files being written.

maybe something like a localize-print function lprintf. Original calls to printf get changed to lprintf:

[CODE]// skipping the C function definition, externs, whatever, here for brevity
// sprintf to generate nativemessage string, then
if ( localizationlanguage != authorsnativelanguage ) {
// a bit of sprintf to assemble the translated phrases and program-generated numbers into localizedmessage
printf "%s \(%s\)\n", localizedmessage, nativemessage;
// with due regard for message lengths, line wrap, etc.
} else {
printf "%s\n", nativemessage; # no point in duplicating same language
}[/CODE]I would probably put the same construct in a single log file with the relevant date/time stamps & TZ indicators.

If using localized log file and authors-language log file separately, how does the user identify what to collect for an issue report; matching time stamps after consideration of possible UTC offset differences between the log files, and perhaps verifying the result of collection matches up by using online translation, seems unnecessarily tedious, compared to grabbing a single section in a single file that is
[CODE]user's selected TZ format time stamp
localized message
(author's language message)[/CODE]