set showstopper flag

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.

(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

*** Issue 122536 has been marked as a duplicate of this issue. ***

*** Issue 122537 has been marked as a duplicate of this issue. ***

Created attachment 80845 [details]
RU registry

Created attachment 80854 [details]
Revision 1465678 in one big patch

Created attachment 80855 [details]
Revision 1465678 split in several patches per file

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.

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)

(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.

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>

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).

(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

>> /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.

(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.

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"

*** Issue 122550 has been marked as a duplicate of this issue. ***

@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

fixed on trunk