Re: how to check if my local copy of translations is really up-to-date?

2017-02-27 Thread Jean-Baptiste Faure

Hi Christian, *,
Le 27/02/2017 à 13:09, Christian Lohmaier a écrit :

[...]
Ah!, good catch.
It is the way the po files are processed/generated. It is picky about
the syntax.

In this case, the
}
;

is the problem. This will make the po-parsing/translation processing
add the next identifier to the context of all strings that follow,
making them not match anymore..


Thank you very much, it's fixed now in my builds for 5.3.2.0.0+ and 
5.2.7.0.0+.


I will build the master next night. I guess that this fix solves the 
problem with the keyID that are not shown in these tooltips.


Best regards.
JBF

--
Seuls des formats ouverts peuvent assurer la pérennité de vos documents.
Disclaimer: my Internet Provider being located in France, each of our
exchanges over Internet will be scanned by French spying services.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: how to check if my local copy of translations is really up-to-date?

2017-02-27 Thread Christian Lohmaier
Hi Jean-Baptiste, *,

On Sun, Feb 26, 2017 at 10:18 PM,   wrote:
> Le 24.02.2017 13:09, Christian Lohmaier a écrit :
>>
>>
>> So to be  clear:
>> source/fr/svx/source/stbctrls.po has the translation in your checkout,
>> but in LibreOffice UI it is still untranslated?
>
>
> Yes. The bug 106082 has been confirmed on LO 5.2.6.1, at least for French
> and Italian.
>
> Today I bisected the bug on the 5.2 branch (less commits to test), and the
> first bad commit is:
>
> commit 3687612a93813449cfc68ce5ece3b785560b2e58

> My C++ (non-)knowledge does not allow me to detect what change in this
> commit triggered the bug.

Ah!, good catch.
It is the way the po files are processed/generated. It is picky about
the syntax.

In this case, the
}
;

is the problem. This will make the po-parsing/translation processing
add the next identifier to the context of all strings that follow,
making them not match anymore..

Fix is easy enough.

(won't have the new string "Could not load all SmartArts….", but will
have all the strings that are in pootle)

ciao
Christian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: how to check if my local copy of translations is really up-to-date?

2017-02-27 Thread Jean-Baptiste Faure

Le 26/02/2017 à 22:18, jbfa...@libreoffice.org a écrit :

[...]
I did that to check that the string is translated in Pootle and that the
translation is in the po files in my local copy.


Argh! I searched the string in Pootle, not the keyID. And surprinsingly, 
these tooltips and the contextual menu do not show their keyID in the 
UI. A priori that is a bug too.


For the tooltip "Zoom level. Right-click to change zoom level or click 
to open Zoom dialog.", the keyID is FMUcP.


Best regards.
JBF

--
Seuls des formats ouverts peuvent assurer la pérennité de vos documents.
Disclaimer: my Internet Provider being located in France, each of our
exchanges over Internet will be scanned by French spying services.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: how to check if my local copy of translations is really up-to-date?

2017-02-26 Thread jbfaure

Hi Christian, *,

Le 24.02.2017 13:09, Christian Lohmaier a écrit :

Hi  Jean-Baptiste,  *,

On Sun, Feb 19, 2017 at 9:38 AM, Jean-Baptiste Faure
 wrote:


Is there a mean to check if the command "./g pull -r" did its job 
correctly,

that is if the local translations subdirectory is really up-to-date.


git submodule status

if that has any character other than space before the git-hash, then
the state of the submodule is not what the core module expects.


Thank you for this command. I did that and my local copy is ok.




I did ./g fetch without change in the local translations subdirectory.


fetch won't touch your checkout.


[1] https://bugs.documentfoundation.org/show_bug.cgi?id=106082


Best way to go for those kind of things is:
A) use key-ID language of the branch to see what keyID the string  in
question has
B) check in pootle whether the string using that keyID is actually 
translated

C) check timeline of the string in pootle, it might have been
translated after the translations have been added to the repository
D) git grep in translations submodule for the string/look in po files
in translations repo whether translation is in there


I did that to check that the string is translated in Pootle and that the 
translation is in the po files in my local copy.




In this case, the translation is in the translations repo, and is also
applied for my build.

So to be  clear:
source/fr/svx/source/stbctrls.po has the translation in your checkout,
but in LibreOffice UI it is still untranslated?


Yes. The bug 106082 has been confirmed on LO 5.2.6.1, at least for 
French and Italian.


Today I bisected the bug on the 5.2 branch (less commits to test), and 
the first bad commit is:


commit 3687612a93813449cfc68ce5ece3b785560b2e58
Author: Miklos Vajna 
Date:   Fri Feb 3 08:35:59 2017 +0100

tdf#105707 PPTX import: warn when SmartArt is missing DrawingML 
fallback


By the time DiagramGraphicDataContext::onCreateContext() completes, 
we

know if there will be a DrawingML fallback for the SmartArt (called
ExtDrawing in the code) or not.

Warn about this case once at the end of the import when in 
interactive

mode. Headless mode silently ignores the warning as expected.

(cherry picked from commit ae828495be9c2ac5fdb4c1747ed7bdd51e5d87a7)

Conflicts:
include/svx/dialogs.hrc
oox/source/core/xmlfilterbase.cxx

Change-Id: I2bfeeedcaa244f08d8a0c208167e79d7bb697e6d
Reviewed-on: https://gerrit.libreoffice.org/33873
Tested-by: Jenkins 
Reviewed-by: Caolán McNamara 
Tested-by: Caolán McNamara 

My C++ (non-)knowledge does not allow me to detect what change in this 
commit triggered the bug.


Best regards.
JBF
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: how to check if my local copy of translations is really up-to-date?

2017-02-24 Thread Christian Lohmaier
Hi  Jean-Baptiste,  *,

On Sun, Feb 19, 2017 at 9:38 AM, Jean-Baptiste Faure
 wrote:
>
> Is there a mean to check if the command "./g pull -r" did its job correctly,
> that is if the local translations subdirectory is really up-to-date.

git submodule status

if that has any character other than space before the git-hash, then
the state of the submodule is not what the core module expects.

> I did ./g fetch without change in the local translations subdirectory.

fetch won't touch your checkout.

> [1] https://bugs.documentfoundation.org/show_bug.cgi?id=106082

Best way to go for those kind of things is:
A) use key-ID language of the branch to see what keyID the string  in
question has
B) check in pootle whether the string using that keyID is actually translated
C) check timeline of the string in pootle, it might have been
translated after the translations have been added to the repository
D) git grep in translations submodule for the string/look in po files
in translations repo whether translation is in there

In this case, the translation is in the translations repo, and is also
applied for my build.

So to be  clear:
source/fr/svx/source/stbctrls.po has the translation in your checkout,
but in LibreOffice UI it is still untranslated?

ciao
Christian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: how to check if my local copy of translations is really up-to-date?

2017-02-21 Thread Jean-Baptiste Faure

Hi Julien, Gabor,

Thank you very much for your answers.

Le 19/02/2017 à 14:18, Gabor Kelemen a écrit :

[...]
My first guess would be that the translations repo is not set to the
same branch as core. To check, use
git branch
on both the core repo and the translations subdirectory.
If the outputs don't match, that's a problem.
You might have set the core repo to the stable branch and not the others
(translations, helpcontent2, dictionaries) - the g script doesn't sync
branch names AFAIK.


I checked my local copy of translations. The translation of the tooltips 
for the zoom slider are in

translations/source/fr/svx/source/stbctrls.po
and my local copy has the strings in French

As now my phone line has been repaired, I did a new local clone of 
branch libreoffice-5-3 but I have the same problem with this local 
repository.


If I am not wrong these tooltips related to zoom slider are in the file 
../program/resource/svxfr.res. I found the english string in this file 
in my own builds for 5.3.2.0.0+ and 5.2.6.0.0+ and in the test build for 
LO 5.2.6 RC1. Finally I installed the test build for LO 5.2.6.1 with FR 
localization and a new user profile and it has the same behavior.
I tested the Italian localization of LO 5.2.6 RC1 with the same behavior 
as for French.


So I guess there is a problem with the merge of FR translation.

I updated my bug report: 
https://bugs.documentfoundation.org/show_bug.cgi?id=106082


Best regards.
JBF

--
Seuls des formats ouverts peuvent assurer la pérennité de vos documents.
Disclaimer: my Internet Provider being located in France, each of our
exchanges over Internet will be scanned by French spying services.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: how to check if my local copy of translations is really up-to-date?

2017-02-19 Thread Gabor Kelemen
Hi

2017-02-19 09:38 keltezéssel, Jean-Baptiste Faure írta:
> Hi,
>
> I build LO 5.3 branch (currently 5.3.1.0.0+) with French translation
> for QA purpose. In my build, some strings are not translated (see [1])
> and I am not sure if the problem is not in my local copy.
>
> Is there a mean to check if the command "./g pull -r" did its job
> correctly, that is if the local translations subdirectory is really
> up-to-date.

My first guess would be that the translations repo is not set to the
same branch as core. To check, use
git branch
on both the core repo and the translations subdirectory.
If the outputs don't match, that's a problem.
You might have set the core repo to the stable branch and not the others
(translations, helpcontent2, dictionaries) - the g script doesn't sync
branch names AFAIK.

Regards
Gabor Kelemen



signature.asc
Description: OpenPGP digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: how to check if my local copy of translations is really up-to-date?

2017-02-19 Thread julien2412
Hello Jean-Baptiste,

I don't know if there's a such command but I noticed that sometimes, ./g
pull -r doesn't work as I expect.
I must go to translations directory and run 'git pull -'.
Sometimes, I notice it's lost its branch so I force with "git checkout
master" then I rerun "git pull -r"

Julien



--
View this message in context: 
http://nabble.documentfoundation.org/how-to-check-if-my-local-copy-of-translations-is-really-up-to-date-tp4208354p4208365.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice


how to check if my local copy of translations is really up-to-date?

2017-02-19 Thread Jean-Baptiste Faure

Hi,

I build LO 5.3 branch (currently 5.3.1.0.0+) with French translation for 
QA purpose. In my build, some strings are not translated (see [1]) and I 
am not sure if the problem is not in my local copy.


Is there a mean to check if the command "./g pull -r" did its job 
correctly, that is if the local translations subdirectory is really 
up-to-date.

I did ./g fetch without change in the local translations subdirectory.
I can't download the complete repository again because currently I have 
a too bad connection to download several GB of data.


Best regards.
JBF

[1] https://bugs.documentfoundation.org/show_bug.cgi?id=106082
--
Seuls des formats ouverts peuvent assurer la pérennité de vos documents.
Disclaimer: my Internet Provider being located in France, each of our
exchanges over Internet will be scanned by French spying services.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice