Created attachment 8703 [details]
Remove schema from localize extractions

The common mechanism for extracting and merging strings is to detect
all localizable files within the source tree and extract the
corresponding strings. From my perspective, we have to split up the
schema files and to remove the text items form OOo cvs.
Thomas, we have to figure out how to deal with this issue for upcoming
releases. 
Please comment this or lets talk face to face about this.

-

From the developer's point of view I would like to keep at least the
english desc-elements in the original xcs files, as they provide
valuabe context information. Splitting all desc-elements into a
seperate project (maybe even outside OOo) will increase the work
needed to find the infos about the config items. I have no objections
regarding the partitioning of the _translated_ desc elments into
different files or even into a module outside the OOo cvs. (We need to
keep in mind the consequnces for the SCM/APOC deployment process, though).

NF: As discussed returned to you.

As the tools are in change a lot for 2.0 to support isoc codes instead
of numeric and symbolic representation, I target this one also for 2.0.

Ause, could you please advise Ivo how to exclude the schemas when
executing localize within the OOo environment (we need them within Sun!)?

.

@hjs: you were not in CC.

BTW - the same happens in fix3 with filter:

pavel@pavel:~/.ooo/ooo_1.1.1_src> grep -r "Specifies if tracing is enabled if im
porting" filter
filter/source/filtertracer/filtertracer.xcs:                                  
<desc xml:lang="en-US">Specifies if tracing is enabled if importing PowerPoint
files.</desc>

localize -e extracts strings from this file.

i would suggest to seperate "SO only" configuration items to a seperate module.
we had a hard time to remove things like "if staroffice build" and get the build
as similar as it is now. introducing new different behaviour doesn't look that
atractive to me...

@ause: This does not have anything to do with 'SO-only' configuration items.
There is no such thing and there really mustn't be. If we ever need something
like this it would need to go into a different xcs file and yes, that could be
placed into a different module.

Generally the situation is as follows:
- Configuration schemas in the source tree contain human readable descriptions.
These descriptions can serve as documentation for developers or administrators.
- The configuration schema descrption element are marked up with a languge
identifier. This permits localization.
- Translated descriptions could be useful to non-english-speaking developers or
administrators - if they find them.

At build and install time the situation is as follows:
- Currently descriptions are stripped from schema files during the build, so
installed schema files don't contain descriptions in any language.
- During the build descriptions are collected into language-specific
*.properties files (Java Resource Bundle format). These decriptions are (or can
be) packed and installed. 
- There is currently (in SRC680) no program that uses these translations (not
even in SO). There used to be an add-on to SO that picked up these files from an
SO installation, but that is being removed (in SRC680). Thus there is no current
requirement that anyone spend resources on localizing this stuff in SRC680. In
SRX645 translation is needed for SO (only).

Future:
- I still hope that we will eventually get a generic configuration editor
(similar to regedit or gconf-editor). To be useful such an editor needs to
provide help about the meaning and content of configuration items. In an
international product such help needs to be localized.
- Alternatively we could at least generate configuration item documentation -
e.g. for the OOo website. This information would then be available to developers
and administrators as guidance for changing configuration data manually or via
macros. Here it may be beneficial to provide localized documents as well.
- When either of this becomes reality, localization (and possibly installation)
of the descriptions will be needed again.

Some requirements for a solution:
- A description (at least in english) should be kept in any case. It is needed
(at least) as developer documentation.
- That english text should still be marked as being english.
- It would be useful (e.g. for API developers and administrators), if at least
the english description is deployed as part of an installation.  If it is only
one language, it may be better to keep that data within the deployed schema
files. Due to our caching strategy that should not even cause a significant
performance hit.
- The changes (in source, build and deployment handling) should allow
reintroducing translation of these strings in the future.
- For now localize should not extract these strings. Building (or at least
installing) of the *.properties files should be suppressed.

as discussed -> jb

I now resolved this as follows:
- all localizations, except en-US were removed from officecfg
- the xml:lang attribute was dropped from the en-US <desc> and <label> elements

Technically they inherit the xml:lang="en-US" designation from the root
(oor:component-schema) element.

But that designation is not picked up by localize, so the strings aren't extracted.

Additionally the descriptions are now handled differently:
- No more .properties files are generated in registry/res/*
- The (english) descriptions are kept in the generated xcs files.

This way the documentational items become available directly in the installed
schemas, which should make them more useful for interested users (e.g. developers)

cfgex does not find anything to extract in registry/schema on CWS scp2officecfg
-> VERIFIED

In SRC680_m53 there are still several <desc> elements containing xml:lang tags
(though only for en-US). To enforce the new convention xml:lang should be
removed from the ATTLIST of <desc> and <label> elements in component-schema.dtd

Fixed in cws cfglooseends.

Any remaining  desc or label elements with xml:lang tags were cleaned up.

There now is a check in schema_val.xsl, which throws an error, if such a
construct is reintroduced.

checked on cws -> verified

@pjanik: This should finally be OK in SRC680m64.

Please close the sissue, if you can verify this.

jb: yes. Closing.