After pointing out to these issues in help files like draw.po, writer.po etc. it also appears in calc/01.po, in several places. One variable definition: par_id962376762132 msgid "<variable id=\"func_define_complex\"><emph>Complex_number</emph> - A string representing a complex number, a real number in either string or number format, or a reference to a cell containing a number</variable>" Is then used in composing strings in the same po file, like shown below, which seems to be unacceptable for some languages: par_id2890729435632 msgid "<embedvar href=\"text/scalc/01/ful_func.xhp#func_define_complex\"/> whose cosine is to be calculated." ******************* par_id766137661376613 msgid "<embedvar href=\"text/scalc/01/ful_func.xhp#func_define_complex\"/> whose hyperbolic cosine is to be calculated." ******************* par_id766137661376613 msgid "<embedvar href=\"text/scalc/01/ful_func.xhp#func_define_complex\"/> whose cotangent is to be calculated." ******************* par_id1899971619670 msgid "<embedvar href=\"text/scalc/01/ful_func.xhp#func_define_complex\"/> whose cosecant needs to be calculated." ******************* par_id1899971619670 msgid "<embedvar href=\"text/scalc/01/ful_func.xhp#func_define_complex\"/> whose hyperbolic cosecant needs to be calculated." ******************* par_id3186739645701 msgid "<embedvar href=\"text/scalc/01/ful_func.xhp#func_define_complex\"/> whose secant needs to be calculated." ******************* par_id31259109804356 msgid "<embedvar href=\"text/scalc/01/ful_func.xhp#func_define_complex\"/> whose hyperbolic secant needs to be calculated." ******************* par_id31206835928272 msgid "<embedvar href=\"text/scalc/01/ful_func.xhp#func_define_complex\"/> whose sine needs to be calculated." ******************* par_id31206835928272 msgid "<embedvar href=\"text/scalc/01/ful_func.xhp#func_define_complex\"/> whose hyperbolic sine needs to be calculated." ******************* par_id10242899132094 msgid "<embedvar href=\"text/scalc/01/ful_func.xhp#func_define_complex\"/> whose tangent is to be calculated."
Is it unacceptable for Slovenian, in particular? @Olivier: Generally I fully agree that composing sentences from variable particles should be avoided. One never knows, if it causes issues in some languages (word order, declination, etc.). For repeated similar lexemes, the translation memory is there to help.
Well, yes, stylistically it is not acceptable, as the sentence: <emph>Complex_number - A string representing a complex number, a real number in either string or number format, or a reference to a cell containing a number is very long, and adding to that the next string: whose cosine is to be calculated. Makes is unclear, whether the cosine is to be calculated from the lastly mentioned number (contained in a cell) or something else, and definitely not from the Complex_number. So replacing the embedvar with just "Complex_number" would solve it. If people need to know what complex_number is, it could always be connected with a hyperlink to the definition itself.
When I was making these pages, I asked myself whether I could make it that way. I had doubts and asked one Russian translator about this situation. And I got the answer that this not just could be done, but it needed being done. And I want to ask: do we really have to translate the same lexeme ten times? Answering on this question, we need to remember that every month we have a new localization. And we need to think about a reduction of lexemes without loss of quality. I don't see any problem for translation into Russian and Belorussian languages, even if we don't know the beginning of the sentence “whose cosine is to be calculated” (but we actually know, because we can see the reference). And besides we reduce the probability of mistakes or a more simple and fast way to fix them. It is easy to correct this. It takes about a few seconds (for example, using the tool sed). But let us really weight the pros and cons.
I think this example and demand should become a rule-of-thumb, as suggested by timar and miles. a) No external particles (lexemes) in a sentence. b) on existence of repeated sentences, use the translation memory of our translation tools. I also think that in this particular case, the explanation of a complex number is a bit excessive and can be reduced as indicated by comment #2. (there will always be a trade-off between factual description of the function and a more elaborate explanation of the mathematical property of the function. I have no rule here, just common sense)
Olivier Hallot committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/help/commit/?id=212af7230d3cd56185c9ff8548a2e61b78b6bd6f tdf#95968 Do not assemble help text with parts
Olivier Hallot committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/help/commit/?id=e5e67c99e8b569eefc91112ff049a89d64affab0&h=libreoffice-5-1 tdf#95968 Do not assemble help text with parts