Language localization for GIMPS software.

[Zhangrc]

Originally Posted by Prime95

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.

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.

[Prime95]

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

[retina]

Originally Posted by Prime95

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.

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".

[kriesel]

Something that occurs to me is English synonyms might translate differently in different languages or different phrases.
at iteration becomes bei iteration,
by iteration (durch Iteration),
to iteration becomes zur iteration in German.
upon iteration (bei 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.)

[Zhangrc]

Originally Posted by retina

English: "Roundoff error of %g. At iteration %d. Rolling back to last save file %s".

Chinese: "在第%d轮迭代出现%g的取整误差，回退到上一存储文件%s。" Notice that the order of %g and %d has been adjusted.

[kruoli]

Originally Posted by kriesel

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

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

Originally Posted by kriesel

Something that occurs to me is English synonyms might translate differently in different languages or different phrases. […]

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.

[axn]

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.

[xilman]

Originally Posted by axn

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.

+1

[slandrum]

Originally Posted by axn

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

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.

[kriesel]

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

// 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
}

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

user's selected TZ format time stamp
localized message
(author's language message)

[LaurV]

Few products we made in the past (like pH Controllers, or programmers for rotary encoders, etc) can "speak" more languages (English, German, Spanish, Dutch, French, Italian, Portuguese, Russian, Romanian, Turkish) and we always keep the languages in separate files that we can edit in text mode, which evolved to be quite complex along the years, each line has an index of the message (same for all languages, to know what is translated, this is the connection between the files, the "unique key"), the position on screen (some messages are longer, or shorter, they may need to be moved few pixels in this or that directions, etc) and the alignment (left, centered, right, which accommodates well for tables, variable numbers, etc., as well as languages that are read from right to left, albeit we never used one of those), font and size (if the device accepts more fonts and sizes, mostly they do not, we just stay at 5x7 fonts for small LCDs incorporated in such products), then the message effectively, with format specifiers, conditions, and \n characters (some messages may need more lines, as they don't fit the small screen). The "conditions" part is tricky business, for example, that will allow to display "1 hour", but say "n hours" if the n is not 1. This was necessary because in some languages the sentence structure changes according with the numbers in the sentence, which you can not "fix in stone" in a dictionary-like file, without "ifs" and "loops" and a lot of programming logic. But the idea was to eliminate the logic from the dictionary files, which we succeeded very well, and the effect is that we can just supply the dictionary files separate and edit them in text mode when necessary, without changing the firmware. The texts effectively (except for Romanian) - we always asked the customer to supply them, and we just put them in the files. They (the customers) have, usually, branches in all these countries, and they have native speakers of those languages "at hand", so they would "take the responsibility" of how they want their product to look like. Also, some fields are editable, and the device only has 3 or 4 buttons (up, down, enter, escape, etc), and the format specifiers also know if the value you put there is fixed or editable, input or output, etc (they are treated differently, can you guess why?).