Issue 122518 - Localized versions fail to start
Localized versions fail to start
Status: RESOLVED FIXED
Product: General
Classification: Code
Component: code
4.0.0-dev
All All
: P3 normal (vote)
: 4.0.0
Assigned To: jsc
:
: 122536 122537 122550 (view as issue list)
Depends on:
Blocks: 122534
  Show dependency treegraph
 
Reported: 2013-06-12 09:43 UTC by Ariel Constenla-Haile
Modified: 2013-07-21 10:10 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation on: ---
Developer Difficulty: ---
jsc: 4.0.0_release_blocker+


Attachments
Patch (3.23 KB, patch)
2013-06-12 09:43 UTC, Ariel Constenla-Haile
no flags Details | Diff
RU registry (968.27 KB, text/plain)
2013-06-14 06:21 UTC, Ariel Constenla-Haile
no flags Details
Revision 1465678 in one big patch (151.68 KB, patch)
2013-06-14 19:02 UTC, Ariel Constenla-Haile
no flags Details | Diff
Revision 1465678 split in several patches per file (75.90 KB, multipart/x-zip)
2013-06-14 19:05 UTC, Ariel Constenla-Haile
no flags Details
Proof of concept for install-module="hungarian" (2.94 KB, patch)
2013-06-17 07:23 UTC, Ariel Constenla-Haile
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Ariel Constenla-Haile 2013-06-12 09:43:18 UTC
Created attachment 80820 [details]
Patch

With the Spanish language pack or the Spanish full install set, the application refuses to start:

No se puede iniciar la aplicación. 
Se produjo un error general mientras se accedía a la configuración central. 

There are two boolean values in the registry translated to Spanish:

[ariel@localhost res]$ diff -uNrp registry_es.xcd registry_es.xcd.new
--- registry_es.xcd     2013-06-12 05:59:23.747430133 -0300
+++ registry_es.xcd.new   2013-06-12 05:57:14.038554437 -0300
@@ -4,10 +4,10 @@
         <node oor:name="View">
             <node oor:name="Localisation">
                 <prop oor:name="AutoMnemonic">
-                    <value xml:lang="es">verdadero</value>
+                    <value>true</value>
                 </prop>
                 <prop oor:name="DialogScale">
-                    <value xml:lang="es">10</value>
+                    <value>10</value>
                 </prop>
             </node>
         </node>
@@ -5494,7 +5494,7 @@
         <node oor:name="Insert">
             <node oor:name="Caption">
                 <prop oor:name="CaptionOrderNumberingFirst">
-                    <value xml:lang="es">verdadero</value>
+                    <value>true</value>
                 </prop>
                 <node oor:name="WriterObject">
                     <node oor:name="Table">

They correspond to

https://translate.apache.org/es/aoo40/translate.html#search=CaptionOrderNumberingFirst&sfields=locations
https://translate.apache.org/es/aoo40/translate.html#search=AutoMnemonic&sfields=locations


There are other places where oor:localized="true"/<value xml:lang="en-US"> is used where it shouldn't (see patch).

In one place I'm not sure: http://svn.apache.org/viewvc/openoffice/trunk/main/officecfg/registry/data/org/openoffice/Office/Writer.xcu?revision=1465678&view=markup#l701
701 	<node oor:name="Layout" >
702 	<node oor:name="Other" >
703 	<prop oor:name="TabStop">
704 	<value xml:lang="en-US">740</value>
705 	</prop>
706 	</node>
707 	</node>

Though TabStop is int, the value might be localized.
Comment 1 jsc 2013-06-12 11:11:11 UTC
set showstopper flag
Comment 2 hanya 2013-06-13 07:59:44 UTC
The value for Tools - Options - Writer - AutoCaption - Caption order was 
"Category first" on 3.4. 
But in the recent trunk, "Numbering first" is default for all languages.

On revision 1465678, xml:lang value of CaptionOrderNumberingFirst entry has been changed from hu to en-US. 
But all languages except for hu was void (and its default value was chosen in main/sw/source/ui/config/modcfg.cxx). It contains special treatment for Hungarian 
and default value for the Hungarian is true.
Comment 3 Ariel Constenla-Haile 2013-06-13 08:17:41 UTC
(In reply to hanya from comment #2)
> The value for Tools - Options - Writer - AutoCaption - Caption order was 
> "Category first" on 3.4. 
> But in the recent trunk, "Numbering first" is default for all languages.
> 
> On revision 1465678, xml:lang value of CaptionOrderNumberingFirst entry has
> been changed from hu to en-US. 

Sure jani didn't want to change that.

In any case, this isn't the proper way of marking a configuration item as requiring a special locale- dependent treatment, it is rather error prone - as can be seen in the Spanish translation.

There is the install:module="some_module" that seems to be proper for such cases as it used for other locale dependent settings like install:module="cjk", install:module="ctl", install:module="korea".

If Hungarian needs a special treatment of CaptionOrderNumberingFirst, this can be set using a install:module.

That said, I have no idea how they work, but they end up on the language packs and localized install sets.

Example:

  <node oor:name="AutoCorrect">
    <prop oor:name="ReplaceSingleQuote" install:module="korea">
      <value>true</value>
    </prop>
  </node>

ends up in Common-korea.xcu
Comment 4 Ariel Constenla-Haile 2013-06-14 06:17:55 UTC
*** Issue 122536 has been marked as a duplicate of this issue. ***
Comment 5 Ariel Constenla-Haile 2013-06-14 06:19:07 UTC
*** Issue 122537 has been marked as a duplicate of this issue. ***
Comment 6 Ariel Constenla-Haile 2013-06-14 06:21:45 UTC
Created attachment 80845 [details]
RU registry
Comment 7 Ariel Constenla-Haile 2013-06-14 19:02:10 UTC
Created attachment 80854 [details]
Revision 1465678 in one big patch
Comment 8 Ariel Constenla-Haile 2013-06-14 19:05:45 UTC
Created attachment 80855 [details]
Revision 1465678 split in several patches per file
Comment 9 Ariel Constenla-Haile 2013-06-14 19:23:29 UTC
Revision 1465678 has several changes that can be grouped in:

a) removal of translations, most of them German strings from resource file

b) removal of comments flagged with x-comment

- Empty comments are safe to remove
- Comments intended for translator, that give some hint about how a string should be translated, could be kept and then ported to the PO file as comments for the translator
- Comments intended for developers, can be converted to C style comments in SRC files and XML comments in XCU files

c) removal of "x-translate". This is done in the filter module and seems right, for example:

<prop oor:name="UIName">
  <value xml:lang="en-US">%oooxmlformatname% %oooxmlformatversion% Spreadsheet Template</value>
  <value xml:lang="x-translate">%oooxmlformatname% %oooxmlformatversion% Spreadsheet Template</value>
</prop>

There is no need for the x-translate there because marking the value with xml:lang="en-US" marks it already as translatable

d) long strings split in several lines in SRC files have been merged in one single line.
While it may be easier to read SRC files if long lines are split, this change isn't a regression.

e) removal of "x-no-translate" has been done only on main/officecfg/registry/data/org/openoffice/Office/Common.xcu and this is the problematic one

In conclusion, a first analysis reveals that only (e) needs to be reverted.
Comment 10 Ariel Constenla-Haile 2013-06-14 19:35:07 UTC
Special treatment for CaptionOrderNumberingFirst:

--- a/main/officecfg/registry/data/org/openoffice/Office/Writer.xcu
+++ b/main/officecfg/registry/data/org/openoffice/Office/Writer.xcu
@@ -50,7 +50,7 @@
   <node oor:name="Insert">
     <node oor:name="Caption">
       <prop oor:name="CaptionOrderNumberingFirst">
-         <value xml:lang="hu">true</value>
+         <value xml:lang="en-US">true</value>
       </prop>
       <node oor:name="WriterObject">
         <node oor:name="Table">

In the schema main/officecfg/registry/schema/org/openoffice/Office/Writer.xcs it has no default value (does it default to false?)

 <prop oor:name="CaptionOrderNumberingFirst" oor:type="xs:boolean">
<info>
 <desc>Specifies the order of the captions.
If true the Numeber appears in front of the category.</desc>
<label>Caption order: Numbering first</label>
</info>
</prop>

This change has to be reverted.
It would be better to use

      <prop oor:name="CaptionOrderNumberingFirst">
         <value install:module="hungarian">true</value>
      </prop>

with a Writer-hungarian.xcu (have to investigate how this is done)
Comment 11 Ariel Constenla-Haile 2013-06-14 19:40:54 UTC
(In reply to hanya from comment #2)
> On revision 1465678, xml:lang value of CaptionOrderNumberingFirst entry has
> been changed from hu to en-US. 
> But all languages except for hu was void (and its default value was chosen
> in main/sw/source/ui/config/modcfg.cxx). It contains special treatment for
> Hungarian 
> and default value for the Hungarian is true.

The source code points to bug 61007
When fixing this, that bug has to be checked.
Comment 12 Ariel Constenla-Haile 2013-06-14 19:45:03 UTC
Special treatment for Layout/Other/TabStop

--- a/main/officecfg/registry/data/org/openoffice/Office/Writer.xcu
+++ b/main/officecfg/registry/data/org/openoffice/Office/Writer.xcu
@@ -701,7 +701,7 @@
  <node oor:name="Layout" >
   <node oor:name="Other" >
     <prop oor:name="TabStop">
-     <value xml:lang="zh-CN">740</value>
+     <value xml:lang="en-US">740</value>
     </prop>
   </node>
  </node>

This has to be reverted, the default in the schema is 1250, for zh-CN it should be 740.

<prop oor:name="TabStop" oor:type="xs:int">
<info>
<author>OS</author>
<desc>Specifies the distance between tab stops [UNIT=1/100 mm].</desc>
<label>Tab stops</label>
</info>
<value>1250</value>
</prop>
Comment 13 jan iversen 2013-06-15 15:51:05 UTC
All the changes I made was agreed on the dev-list, however of course if they break a build they must be reverted without disucssion (we can always later discuss, why a discussion on the dev list and consensus, isnt enough).

I have now reverted

/trunk/main/officecfg/registry/data/org/openoffice/Office/Common.xcu

I do however highly disagree with the use of non-translateable constants, that at the same time are marked with [en-US] this is highly inconsistent, and can only lead to confusion. The constant is valid in e.g. danish as well, and are not special for [en-US] as indicated.

I have not reverted 
main/sw/source/ui/config/modcfg.cxx or
/main/officecfg/registry/data/org/openoffice/Office/Writer.xcu

as written in other comments (which I highly agree to), this is not the way to use the translation system. If it is a required feature, we can forget the new genLang module.

We agreed on the dev list to remove all non en-US entries.

- Comments intended for translator ... could be kept and then ported to the PO file as comments for the translator

actually this is only partly happening with the current system, some of the comments are very old, and does not reflect the actual translation. We agreed
on the dev-list to remove these comments. If they are to be kept, we can forget the new genLang.

I hope I have replied to all comments, and done the correct reverts. In case something is missing please feel free to do the revert (I will not be offended).
Comment 14 Ariel Constenla-Haile 2013-06-15 16:01:03 UTC
(In reply to jan iversen from comment #13)
> All the changes I made was agreed on the dev-list, however of course if they
> break a build they must be reverted without disucssion (we can always later
> discuss, why a discussion on the dev list and consensus, isnt enough).
> 
> I have now reverted
> 
> /trunk/main/officecfg/registry/data/org/openoffice/Office/Common.xcu

I have already done this as part of revision 1493305 (the commit notification system seems broken) as in

> /main/officecfg/registry/data/org/openoffice/Office/Writer.xcu

a revert here is not enough, this needs a fix by adding x-no-translate in the respective places.

 
> as written in other comments (which I highly agree to), this is not the way
> to use the translation system. If it is a required feature, we can forget
> the new genLang module.

this is partial fix for 4.0.0, the best way seems to be the use of install:module="some_l10n_module", but I have to investigate how this is done. For now let's keep it simple: revision 1493305 as few safe lines, enough for 4.0.0
Comment 15 jan iversen 2013-06-15 16:15:13 UTC
>> /main/officecfg/registry/data/org/openoffice/Office/Writer.xcu

>a revert here is not enough, this needs a fix by adding x-no-translate in the respective places.

If a revert is not enough, then it is something out of my control, I dont really have a clue what the file is intented to do.

jan I.
Comment 16 Ariel Constenla-Haile 2013-06-15 19:15:39 UTC
(In reply to jan iversen from comment #15)
> >> /main/officecfg/registry/data/org/openoffice/Office/Writer.xcu
> 
> >a revert here is not enough, this needs a fix by adding x-no-translate in the respective places.
> 
> If a revert is not enough, then it is something out of my control, I dont
> really have a clue what the file is intented to do.

It is simply adding x-no-translate and then verifying that things works as expected. x-no-translate tells localize not to extract these strings when generating the SDF file, so:

* Before the fix:

- Generate a SDF file:

]$ localize -e -l en-US -f $OUTDIR/aoo400.sdf

- Grep that file for the build breaking entries:

]$ grep -E --line-number 'TabStop|CaptionOrderNumberingFirst|AutoMnemonic|DialogScale' $OUTDIR/aoo400.sdf

52559:officecfg registry\data\org\openoffice\Office\Common.xcu  0       value   ..Common.View.Localisation      AutoMnemonic                    0       en-US   true              20130515 21:47:47
52560:officecfg registry\data\org\openoffice\Office\Common.xcu  0       value   ..Common.View.Localisation      DialogScale                     0       en-US   10                20130515 21:47:47
53772:officecfg registry\data\org\openoffice\Office\Writer.xcu  0       value   ..Writer.Insert.Caption CaptionOrderNumberingFirst                      0       en-US   true      20130515 21:47:47
53793:officecfg registry\data\org\openoffice\Office\Writer.xcu  0       value   ..Writer.Layout.Other   TabStop                 0       en-US   740                             20130515 21:47:47

true, 10, 740 are marked as translatable.
This caused an error on the configuration manager when the boolean values were translated.
The error appears as a build breaker in all platforms when building a package format that runs unopkg sync; on Windows the installer fails, because it runs unopkg.exe; on Linux the application failed to start.

* After the fix: repeat the same steps, grep shows there are no build breaking entries any more.


The other kind of error was to assigning a values to en-US instead of the original. For example, CaptionOrderNumberingFirst with value true should be applied only to hu-HU, all other languages default to false. To verify:

Test with locale en-US
----------------------

- Just in case, reset your profile
- New Writer document
- Open dialog from menu "Tools" - "Options..."
- in the "Options" dialog, select OpenOffice Writer - AutoCaption

* Before the fix:
"Caption order" list box has "Numbering first" and the preview displays "1. Table"

* After the fix:
"Caption order" list box has "Category first" and the preview displays "Table 1:"


Test with locale hu-HU
----------------------

Repeat same steps as before, result after the fix:

"Feliratsorrend" list box has "Számozás elóször" and the preview displays "1. táblázat"


For the other changes a similar verification is needed in the respective locales.
Comment 17 Ariel Constenla-Haile 2013-06-17 07:23:40 UTC
Created attachment 80872 [details]
Proof of concept for install-module="hungarian"

The patch removes the need of using x-no-translate and respective xml:lang="hu" in the value of CaptionOrderNumberingFirst by using a install:module="hungarian"
Comment 18 Ariel Constenla-Haile 2013-06-17 14:18:03 UTC
*** Issue 122550 has been marked as a duplicate of this issue. ***
Comment 19 jsc 2013-06-18 09:12:53 UTC
@Ariel, regarding your patch with the proof of concept for install-module="hungarian". This is something that we should test and integrate for 4.1 together with further testing of the genLang feature, correct. I am trying to get an overview where we are. I would suggest to create a new issue for this for 4.1

@Jan, I don't think that we  have to forget genLang, it needs potentially a little bit more work to take care of all specialties that we have in the code. We agree on the dev list because the idea and logic behind looked good. The point is always the details that we noticed now. A complete testing on the branch with localized builds from the branch would have been better before merging parts back on trunk. This can and will happen in the future and is no problem as long as we can fix it

We should move the discussion on the dev list
Comment 20 jsc 2013-06-27 11:11:22 UTC
fixed on trunk