Topic: Preparing for translation

kaputtnik wrote:

Some questions about preparing for translation:

npgettext, example:

~~~~ settings_window:get_child("spinbox_label").text = _("Investigate around the ") .. npgettext("around player position:", "player position:", "player positions:", count) ~~~~

Do the arguments to npgettext also need the translation function _("text")? E.g.: npgettext("around player position:", _("player position:"), _("player positions:"), count)

No, ngettext already is the translation function. Translating the arguments again will not work.

Note that string concatenation for translatable texts will lead to grammar errors in languages with a different syntax. Just use one very long ngettext call with the complete text, e.g.

settings_window:get_child("spinbox_label").text = npgettext("around_player_position", "Investigate around the player position:", "Investigate around the player positions:", count)

Also note that we don't usually use ngettext at all just to distinguish singular and plural (and just add a TRANSLATORS comment to let us know if someone needs plural forms), and only use ngettext if the actual number is part of the text.

---

What about such a construct (total_gr, granite and marble are numbers):

~~~~ -- TRANSLATORS: Word or sign which means approximately. Keep it short. local ca = _("ca. ")

text_tmp = text_tmp .. p(("As Resources: ")) .. li_arrow(total_gr .. (" granite ") .. (" or ")) .. li_arrow(ca .. granite .. (" granite ") .. (" and ") .. ca .. marble .. (" marble") ) ~~~~

Will it be sufficient to add a translators comment with an example of the resulting text? Or should each row be a separate translation string?

Again, please no string concatenations, instead use something like

_("ca. %1$s granite and ca. %2$s marble"):bformat(granite, marble)

If a translatable string contains leading or trailing whitespace, you're always doing something wrong.

---

I have also a function that turns a fields table to a string:

~~~~ -- TRANSLATORS: Sign between coordinates like 54/56 local field_sep = _("/")

function get_field_string(f) return f.x .. field_sep .. f.y end ~~~~

Does this need special treating because of the numbers? E.g. using bformat?

Again, yes, use return _("%1$d/%2$d"):bformat(f.x, f.y)

When in doubt, always prefer bformat over concatenation.

Top

Quote

No, join_sentences can be used only for two separate sentences; splitting a sentence into two halves will cause grammar errors. For example in German this concatenation would become "Für eine Beschreibung der Tabellenspalten sieh bitte an / diesen Beitrag im Widelands-Forum" – sounds awkward, the "an" should be moved to the end of the sentence.

join_sentences is just a simple wrapper around _("%1$s %2$s"):bformat(arg1, arg2). In your example just use bformat directly too:

p(
    -- TRANSLATORS: Placeholder is "this post in the Widelands forum"
    _("For a description of the table columns look at %s"):bformat(a(
    -- TRANSLATORS: Will be inserted into "For a description of the table columns look at %s"
    _("this post in the Widelands forum"),
    "url", "https://www.widelands.org/forum/post/41426/")))

Top

Quote

Yes those examples look right.

Splitting for long strings is only necessary for reeeaaaally long texts, as in hundreds of words, and then the real point is that such a text should be better split into several paragraphs; Transifex offers fuzzy string matching so a small change in a long text does not force the translator to type the entire text again.

Whether a text is used as a header is usually not relevant, but adding TRANSLATORS comments to explain how and where a string is used can never hurt

Top

Quote

Identical strings only appear once on Transifex, unless you explicitly disambiguate them with pgettext.

For long strings that are used many times, a variable can still be useful to keep consistency if you ever want to change the phrasing or spelling, but for such a short string used in only 3 places this is not a concern and would IMHO only make the code less readable.

Top

Quote