Re: [libreoffice-l10n] compound strings
2011/12/31 Andras Timar tima...@gmail.com 2011/12/31 Andras Timar tima...@gmail.com: As for the Insert Rows/Columns modal dialog, it was a good catch that needs to be fixed. But if it have been good enough for the last couple of years, then I don't think we need to urgently fix it in 3.5 and break the string freeze. Let's fix it in master. What do you think? http://cgit.freedesktop.org/libreoffice/core/commit/?id=005844765e38b8147ff2468036cc5c229680a1bb Please escalate the issue to libreoff...@lists.freedesktop.org, if you want this in 3-5. Happy New Year! Andras Hi Andras, in Your commit You removed Insert keyid 7yKt but if its meant to use like: 7yKt + btRK = Insert + Rows 7yKt + xGzB = Insert + Columns Shouldn´t btRK and xGzB also be removed? Or are these used for something else? Regards -- Sérgio Marques -- Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/l10n/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-l10n] compound strings
2012/1/3 Sérgio Marques smarque...@gmail.com 2011/12/31 Andras Timar tima...@gmail.com 2011/12/31 Andras Timar tima...@gmail.com: As for the Insert Rows/Columns modal dialog, it was a good catch that needs to be fixed. But if it have been good enough for the last couple of years, then I don't think we need to urgently fix it in 3.5 and break the string freeze. Let's fix it in master. What do you think? http://cgit.freedesktop.org/libreoffice/core/commit/?id=005844765e38b8147ff2468036cc5c229680a1bb Please escalate the issue to libreoff...@lists.freedesktop.org, if you want this in 3-5. Happy New Year! Andras Hi Andras, in Your commit You removed Insert keyid 7yKt but if its meant to use like: 7yKt + btRK = Insert + Rows 7yKt + xGzB = Insert + Columns Shouldn´t btRK and xGzB also be removed? Or are these used for something else? Regards -- Sérgio Marques Hi Andras, ignore my message. I didn´t notice that Row and Columns were changed to Insert Row and Insert Columns Regards -- Sérgio Marques -- Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/l10n/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-l10n] compound strings
2011/12/31 Andras Timar tima...@gmail.com 2011/12/31 Martin Srebotnjak mi...@filmsi.net: So, Andras, will you take care of these two string-formations in the code for 3.5, the one reported by Milos and the one by Mihkel? Or do we have to adapt our translations according to what the author of code wanted to say? Time for 3.5 is running out I guess. I don't understand why anyone needs to adapt translations for Milos' example. Well, for one, in the case of languages that don't use Title Case for menu commands, it's not obvious that words for Header and Footer should start with a lowercase letter there. We have Delete $1 and Format $1 where $1 can be Header or Footer. Those are STR_HEADER and STR_FOOTER from sw/source/ui/docvw/docvw.src and are not used anywhere else, so you can translate them as you need to fit into the Delete $1 context. I hope the translation for Header or Footer is not different depending on if you delete it or if format it. I wouldn't be so sure. In Estonian, Delete header/footer is Kustuta päis/jalus, but Format header/footer could be Vorminda päis/jalus or Vorminda päist/jalust depending on entirety vs. partialness [1]. These words just so happen to both take only 't' at the end in partitive form, so Vorminda $1t would work, but there may be languages where the words change differently. [1] See e.g. http://en.wikipedia.org/wiki/Partitive_case As for the Insert Rows/Columns modal dialog, it was a good catch that needs to be fixed. But if it have been good enough for the last couple of years, then I don't think we need to urgently fix it in 3.5 and break the string freeze. Let's fix it in master. What do you think? OK by me. Happy new year! Mihkel -- Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/l10n/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-l10n] compound strings
Hi Mihkel, 2012/1/2 Mihkel Tõnnov mihh...@gmail.com: We have Delete $1 and Format $1 where $1 can be Header or Footer. Those are STR_HEADER and STR_FOOTER from sw/source/ui/docvw/docvw.src and are not used anywhere else, so you can translate them as you need to fit into the Delete $1 context. I hope the translation for Header or Footer is not different depending on if you delete it or if format it. I wouldn't be so sure. In Estonian, Delete header/footer is Kustuta päis/jalus, but Format header/footer could be Vorminda päis/jalus or Vorminda päist/jalust depending on entirety vs. partialness [1]. These words just so happen to both take only 't' at the end in partitive form, so Vorminda $1t would work, but there may be languages where the words change differently. Thanks for this great example. Now we have the proof that it can cause problem. I'll kill this composition from master, too. Please report, if you find more. Best regards, Andras -- Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/l10n/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-l10n] compound strings
Dňa 31.12.2011 13:56, Andras Timar wrote / napísal(a): 2011/12/31 Martin Srebotnjak mi...@filmsi.net: I guess the conservatism of OOo team when designing UI with those UI spec documents was a good thing and this should be in a way incorporated in the LO development process, even if with a lower administration impact on developers - but there should be some l10n representative checking ALL the proposed changes of UI strings - that they are logical and that they are localizable in all 100+ languages. Only then they could be checked in. No, that would effectively kill productivity. It is better to catch issues in beta phase. Not to mention that the UI approved by a comittee in the Sun era still resulted crap. See the history of http://opengrok.libreoffice.org/history/core/cui/source/dialogs/insrc.src, it is Mihkels example. This file has not been touched by LibreOffice developers. So, Andras, will you take care of these two string-formations in the code for 3.5, the one reported by Milos and the one by Mihkel? Or do we have to adapt our translations according to what the author of code wanted to say? Time for 3.5 is running out I guess. I don't understand why anyone needs to adapt translations for Milos' example. We have Delete $1 and Format $1 where $1 can be Header or Footer. Those are STR_HEADER and STR_FOOTER from sw/source/ui/docvw/docvw.src and are not used anywhere else, so you can translate them as you need to fit into the Delete $1 context. I hope the translation for Header or Footer is not different depending on if you delete it or if format it. No, it is not different. So, I corrected the translation to the accusative case without the capital letter. I could have done that also earlier (thanks to KeyId), but I was not sure if these string were used elsewhere in a different context (say, in nominative) or not. Now I know :) Thanks Milos As for the Insert Rows/Columns modal dialog, it was a good catch that needs to be fixed. But if it have been good enough for the last couple of years, then I don't think we need to urgently fix it in 3.5 and break the string freeze. Let's fix it in master. What do you think? Best regards, Andras -- email jabber: sramek.mi...@gmail.com -- Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/l10n/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-l10n] compound strings
Hi Donald et. al., 2011/12/29 Donald Rogers donr2...@clear.net.nz On the other hand, is this a mechanism for developers to save us lots of work, retranslating the same strings over and over, e.g. OK, Cancel? this is not a proper reason to compound strings this way. There are tons of Cancels and OKs in the string pool, and they should be kept separate. The point is that the number of strings actually gets higher: if you compound three strings with same beginning, you have 4 strings to translate instead of 3. Yes, they are shorter, but in languages with cases, such as all Slavic ones, you get incorrect translations. So 10 languages are ok and all the rest not ... I guess the conservatism of OOo team when designing UI with those UI spec documents was a good thing and this should be in a way incorporated in the LO development process, even if with a lower administration impact on developers - but there should be some l10n representative checking ALL the proposed changes of UI strings - that they are logical and that they are localizable in all 100+ languages. Only then they could be checked in. So, Andras, will you take care of these two string-formations in the code for 3.5, the one reported by Milos and the one by Mihkel? Or do we have to adapt our translations according to what the author of code wanted to say? Time for 3.5 is running out I guess. Last but not least - all best in the upcoming year to every single LO-l10n contributor! m. -- Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/l10n/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-l10n] compound strings
Quite. Even the little compounding we have leads to problems in highly inflected languages. Yes/No is another of those, which is unfortunately one that the OO team forgot, because a great many languages don't have a single word for yes and no and rely on the repetition of the verb. The only way in which you could increase compounding without forcing crap translations in a lot of languages would be using something like Pology (http://websvn.kde.org/trunk/l10n-support/pology/doc/user/) but I suspect that's not going to happen in a hurry. That aside, Bliadhna Mhath Ùr/Happy New Year to y' all! Michael 31/12/2011 12:08, sgrìobh Martin Srebotnjak: Yes, they are shorter, but in languages with cases, such as all Slavic ones, you get incorrect translations. So 10 languages are ok and all the rest not ... -- Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/l10n/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-l10n] compound strings
2011/12/31 Martin Srebotnjak mi...@filmsi.net: I guess the conservatism of OOo team when designing UI with those UI spec documents was a good thing and this should be in a way incorporated in the LO development process, even if with a lower administration impact on developers - but there should be some l10n representative checking ALL the proposed changes of UI strings - that they are logical and that they are localizable in all 100+ languages. Only then they could be checked in. No, that would effectively kill productivity. It is better to catch issues in beta phase. Not to mention that the UI approved by a comittee in the Sun era still resulted crap. See the history of http://opengrok.libreoffice.org/history/core/cui/source/dialogs/insrc.src, it is Mihkels example. This file has not been touched by LibreOffice developers. So, Andras, will you take care of these two string-formations in the code for 3.5, the one reported by Milos and the one by Mihkel? Or do we have to adapt our translations according to what the author of code wanted to say? Time for 3.5 is running out I guess. I don't understand why anyone needs to adapt translations for Milos' example. We have Delete $1 and Format $1 where $1 can be Header or Footer. Those are STR_HEADER and STR_FOOTER from sw/source/ui/docvw/docvw.src and are not used anywhere else, so you can translate them as you need to fit into the Delete $1 context. I hope the translation for Header or Footer is not different depending on if you delete it or if format it. As for the Insert Rows/Columns modal dialog, it was a good catch that needs to be fixed. But if it have been good enough for the last couple of years, then I don't think we need to urgently fix it in 3.5 and break the string freeze. Let's fix it in master. What do you think? Best regards, Andras -- Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/l10n/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-l10n] compound strings
Hi Milos, Martin, *, 2011/12/29 Martin Srebotnjak mi...@filmsi.net: 2011/12/28 Martin Srebotnjak mi...@filmsi.net 2011/12/28 Milos Sramek sramek.mi...@gmail.com Hi, I have in the new Header/Footer feature of 3.5 for the first time noticed compound strings consisting of two separately translated strings. For example, Format Header is composed of strings Format (KeyId _XDs) and Header (b4n3). Slovak (and other languages) have cases - the Header word must be in the accusative case here. Are we sure that the b4n3 Header string is used only in such context and not in other, where for example, the nominative case should be used? I would prefer to not to compound strings of other strings. What do you think about that? Can we send this message to the developers? Hi, I haven't noticed that, this should be marked, explained in notes, if sdf had those... Will check, but why is this not a single string? Does that mean that also Format Footer is formed from two strings? This is unacceptable and anglo-saxon-centric, really does not work well for other languages. OMG, now I saw it, this is horrible - each context menu command must be a separate string, you cannot format context menu commands in the same manner for 100+ languages! Thanks, Milos, for noticing this. See also this thread: http://listarchives.libreoffice.org/global/l10n/msg03406.html I agree that composing strings in such a manner is not okay, and should it become a habit with the devs, it's a disaster waiting to strike. Another such case: 7yKt + btRK = Insert + Rows 7yKt + xGzB = Insert + Columns (make a table in Writer, right-click in it, choose Row - Insert or Column - Insert, and behold the dialog title.) I'm not sure if there are more. Greetings, Mihkel The Estonian team -- Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/l10n/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-l10n] compound strings
On 29/12/2011, at 2:52 PM, Mihkel Tõnnov wrote: Hi Milos, Martin, *, 2011/12/29 Martin Srebotnjak mi...@filmsi.net: 2011/12/28 Martin Srebotnjak mi...@filmsi.net 2011/12/28 Milos Sramek sramek.mi...@gmail.com Hi, I have in the new Header/Footer feature of 3.5 for the first time noticed compound strings consisting of two separately translated strings. For example, Format Header is composed of strings Format (KeyId _XDs) and Header (b4n3). Slovak (and other languages) have cases - the Header word must be in the accusative case here. Are we sure that the b4n3 Header string is used only in such context and not in other, where for example, the nominative case should be used? I would prefer to not to compound strings of other strings. What do you think about that? Can we send this message to the developers? Hi, I haven't noticed that, this should be marked, explained in notes, if sdf had those... Will check, but why is this not a single string? Does that mean that also Format Footer is formed from two strings? This is unacceptable and anglo-saxon-centric, really does not work well for other languages. OMG, now I saw it, this is horrible - each context menu command must be a separate string, you cannot format context menu commands in the same manner for 100+ languages! Thanks, Milos, for noticing this. See also this thread: http://listarchives.libreoffice.org/global/l10n/msg03406.html I agree that composing strings in such a manner is not okay, and should it become a habit with the devs, it's a disaster waiting to strike. Another such case: 7yKt + btRK = Insert + Rows 7yKt + xGzB = Insert + Columns (make a table in Writer, right-click in it, choose Row - Insert or Column - Insert, and behold the dialog title.) I'm not sure if there are more. Yes, the same happens in the Esperanto version. It does not even put a space between the two words, and the case of the second is wrong (naturally). On the other hand, is this a mechanism for developers to save us lots of work, retranslating the same strings over and over, e.g. OK, Cancel? Donald -- Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/l10n/ All messages sent to this list will be publicly archived and cannot be deleted
