Apache OpenOffice (AOO) Bugzilla – Issue 113428
CWS ooo330l10n - Huge changeset due to mis-ordering on localize.sdf files
Last modified: 2017-05-20 11:35:22 UTC
The changeset for CWS ooo330l10n is too big, because localize.sdf files have not been ordered before updating, so the diff against the previous version has mostly the same strings removed and added into another position. This makes difficult for the language projects admins to see what lines really were changed / added. IMHO, these changes should be rolled back, all the files ordered, and then committed again. Best regards, Santiago Bosio
we talk about spanish?
there is no ordering implemented right now, the files are just copied how they are into the source tree. I expect that the files always have the same ordering coming out of the localize tool, out of the the pootle system and also out of the usual po files systems. Usually the point is to leave the ordering untouched the way the localize tool extracts them thus there is a logical order of the strings. For example the readme is correct the way from top to buttom. If I sort that file the readme strings would be mixed up.
beside that I already noticed that the diff used in hg is less clever then that used in cvs / svn
I just saw that the extract date in the en-GB is not "normalized", I will look into that now
ihi: sorry, at first sight they seemed ordered, but you're right, they aren't. It must be that bad diff tool, that generates the big changeset.
while looking at the spanish diff I see that there are in some strings the "string length" column changed but the string itself don't. -filter source\pdf\impdialog.src 0 string RID_PDF_TAB_SECURITY STR_USER_PWD_UNSET 160 es Sin contraseña abierta configurada -filter source\pdf\impdialog.src 0 string RID_PDF_TAB_SECURITY STR_USER_PWD_UNENC 160 es El Documento PDF no será encriptado +filter source\pdf\impdialog.src 0 string RID_PDF_TAB_SECURITY STR_USER_PWD_UNSET 0 es Sin contraseña abierta configurada +filter source\pdf\impdialog.src 0 string RID_PDF_TAB_SECURITY STR_USER_PWD_UNENC 0 es El Documento PDF no será encriptado I wonder how this happend. I will "normalize" that column also thus it is always 0 when it comes out of the localize tool. I wonder if the po tools chain somehow modifiy that column itself. It is unlikely that it comes out of th elocalize tool one time with 0 and next time with 160
.
Reset assigne to the default "issues@openoffice.apache.org".