Difference between revisions of "Spellchecker Integration into Installation Set"

From Apache OpenOffice Wiki
Jump to: navigation, search
m (License for your dictionary)
m (removed historical page from its category lists)
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
How to integrate a spellchecker extension into OpenOffice.org / StarOffice installation sets.
+
{{historical}}
 +
 
 +
How to integrate a [[Extension_Dictionaries| spellchecker extension]] into OpenOffice.org / StarOffice installation sets.
  
 
Assuming you provide a spellchecker, dictionary, ... for language xy and already created an extension file dict_xy.oxt . Then your next task is, to add this file into the OpenOffice.org installation set. And the solution for this task is described here. A prerequisite is, that you delivered your spellchecker extension into a directory, where it is found during packaging process. This can be the pck-directory, where all other spellchecker extensions are located at the moment. After you did so, you have to make changes in the'' cvs modules “scp2” and “setup_native” to prepare the packaging process.
 
Assuming you provide a spellchecker, dictionary, ... for language xy and already created an extension file dict_xy.oxt . Then your next task is, to add this file into the OpenOffice.org installation set. And the solution for this task is described here. A prerequisite is, that you delivered your spellchecker extension into a directory, where it is found during packaging process. This can be the pck-directory, where all other spellchecker extensions are located at the moment. After you did so, you have to make changes in the'' cvs modules “scp2” and “setup_native” to prepare the packaging process.
Line 23: Line 25:
 
The module definition happens in the file
 
The module definition happens in the file
  
''scp2/source/ooo/module_hidden_ooo.scp''
+
''scp2/source/ooo/module_ooo.scp''
  
 
The definition looks like this for language “xy”:
 
The definition looks like this for language “xy”:
  
 
     Module gid_Module_Root_Extension_Dictionary_Xy
 
     Module gid_Module_Root_Extension_Dictionary_Xy
         Name = "gid_Module_Root_Extension_Dictionary_Xy";
+
         MOD_NAME_DESC ( MODULE_EXTENSION_DICTIONARY_XY );
        Description = "gid_Module_Root_Extension_Dictionary_Xy";
+
 
         Files = (gid_File_Extension_Dictionary_Xy);
 
         Files = (gid_File_Extension_Dictionary_Xy);
 
         InstallOrder = "2000";
 
         InstallOrder = "2000";
 +
        Sortkey = "<number>";
 
         Spellcheckerlanguage = "xy";
 
         Spellcheckerlanguage = "xy";
 
         PackageInfo = "packinfo_office.txt";
 
         PackageInfo = "packinfo_office.txt";
         ParentID = gid_Module_Root;
+
         ParentID = gid_Module_Dictionaries;
         Styles = (HIDDEN_ROOT);
+
         Styles = ();
 
     End
 
     End
 +
 +
Text displayed in the Windows installer defined in
 +
 +
''scp2/source/ooo/module_ooo.ulf''
 +
 +
The definition looks like this for language “xy”:
 +
 +
    [STR_NAME_MODULE_EXTENSION_DICTIONARY_XY]
 +
    en-US = "Xy"
 +
 +
    [STR_DESC_MODULE_EXTENSION_DICTIONARY_XY]
 +
    en-US = "Xy spelling dictionary and/or hyphenation patterns and/or thesaurus"
  
 
== Changes in cvs module setup_native ==
 
== Changes in cvs module setup_native ==
Line 61: Line 75:
 
     packageversion = "%PACKAGEVERSION"
 
     packageversion = "%PACKAGEVERSION"
 
     End
 
     End
 +
 +
Add the same name to
 +
''setup_native/source/packinfo/package_names.txt''
 +
 +
    %PACKAGEPREFIX%SOLARISBRANDPACKAGENAME%BRANDPACKAGEVERSION-dict-xy Xy dictionary for %PRODUCTNAME %PRODUCTVERSION
  
 
After you defined the package in this way, the last step is the assignment to the product languages. This happens in  
 
After you defined the package in this way, the last step is the assignment to the product languages. This happens in  
Line 111: Line 130:
  
 
That is all you have to do. Now you only have to build cvs module “scp2” and to deliver “scp2” and “setup_native”. Then you can start creation of installation sets in module “instsetoo_native”.
 
That is all you have to do. Now you only have to build cvs module “scp2” and to deliver “scp2” and “setup_native”. Then you can start creation of installation sets in module “instsetoo_native”.
 
  
 
== License for your dictionary ==
 
== License for your dictionary ==
Line 118: Line 136:
  
 
Only dictionaries that do not require user license agreement can be integrated into installation set.
 
Only dictionaries that do not require user license agreement can be integrated into installation set.
 
 
[[Category:Extensions]]
 

Latest revision as of 08:05, 22 June 2012

This page is archived for historical reasons only. It is no longer maintained and information may not be current.

How to integrate a spellchecker extension into OpenOffice.org / StarOffice installation sets.

Assuming you provide a spellchecker, dictionary, ... for language xy and already created an extension file dict_xy.oxt . Then your next task is, to add this file into the OpenOffice.org installation set. And the solution for this task is described here. A prerequisite is, that you delivered your spellchecker extension into a directory, where it is found during packaging process. This can be the pck-directory, where all other spellchecker extensions are located at the moment. After you did so, you have to make changes in the cvs modules “scp2” and “setup_native” to prepare the packaging process.

Changes in cvs module scp2

In the cvs module scp2 you have to define the file, so that it is included into the packaging process, and you have to define a new module, to which this file has to be assigned. For Unix platforms this module is used, to create a Unix package, like a rpm or a Solaris package. The file definition happens in

scp2/source/ooo/file_ooo.scp

For language “xy” you will have to make a file definition like this:

   #ifndef WITHOUT_MYSPELL_DICTS
   File gid_File_Extension_Dictionary_Xy
       Dir = gid_Brand_Dir_Share_Extension_Install;
       Name = "dict-xy.oxt";
       Styles = (PACKED);
       UnixRights = 444;
   End
   #endif

The module definition happens in the file

scp2/source/ooo/module_ooo.scp

The definition looks like this for language “xy”:

   Module gid_Module_Root_Extension_Dictionary_Xy
       MOD_NAME_DESC ( MODULE_EXTENSION_DICTIONARY_XY );
       Files = (gid_File_Extension_Dictionary_Xy);
       InstallOrder = "2000";
       Sortkey = "<number>";
       Spellcheckerlanguage = "xy";
       PackageInfo = "packinfo_office.txt";
       ParentID = gid_Module_Dictionaries;
       Styles = ();
   End

Text displayed in the Windows installer defined in

scp2/source/ooo/module_ooo.ulf

The definition looks like this for language “xy”:

   [STR_NAME_MODULE_EXTENSION_DICTIONARY_XY]
   en-US = "Xy"
   [STR_DESC_MODULE_EXTENSION_DICTIONARY_XY]
   en-US = "Xy spelling dictionary and/or hyphenation patterns and/or thesaurus"

Changes in cvs module setup_native

In the cvs module setup_native you have to assign the module defined in scp2 to a package (see line PackageInfo = “package_office.txt” in the module definition) and you have to define, for which installation sets in which languages your new extension shall be included. So the first file you have to adapt is the file

setup_native/source/packinfo/packinfo_office.txt

Dont be worried about the complexity of the package definition. There are some dependencies, that have to be defined for each package. Luckily they are always the same for all packages containing extensions, so you can simply copy an existing definition, like the one for “gid_Module_Root_Extension_Dictionary_En” and only change the language code:

   Start
   module = "gid_Module_Root_Extension_Dictionary_Xy"
   script = "shellscripts_extensions.txt"
   solarispackagename = "%PACKAGEPREFIX%WITHOUTDOTUNIXPRODUCTNAME%BRANDPACKAGEVERSION-dict-xy"
   solarisrequires = "%SOLSUREPACKAGEPREFIX-ure (Name="UNO Runtime Environment"), %BASISPACKAGEPREFIX%WITHOUTDOTOOOBASEVERSION-core01 (Name="Core module for %PRODUCTNAME %PRODUCTVERSION"), %BASISPACKAGEPREFIX%WITHOUTDOTOOOBASEVERSION-core02 (Name="Core module for %PRODUCTNAME %PRODUCTVERSION"), %BASISPACKAGEPREFIX%WITHOUTDOTOOOBASEVERSION-core03 (Name="Core module for %PRODUCTNAME %PRODUCTVERSION"), %BASISPACKAGEPREFIX%WITHOUTDOTOOOBASEVERSION-core04 (Name="Core module for %PRODUCTNAME %PRODUCTVERSION"), %BASISPACKAGEPREFIX%WITHOUTDOTOOOBASEVERSION-core05 (Name="Core module for %PRODUCTNAME %PRODUCTVERSION"), %BASISPACKAGEPREFIX%WITHOUTDOTOOOBASEVERSION-core06 (Name="Core module for %PRODUCTNAME %PRODUCTVERSION"), %BASISPACKAGEPREFIX%WITHOUTDOTOOOBASEVERSION-core07 (Name="Core module for %PRODUCTNAME %PRODUCTVERSION"), %PACKAGEPREFIX%WITHOUTDOTUNIXPRODUCTNAME%BRANDPACKAGEVERSION (Name="Brand module for %PRODUCTNAME %PRODUCTVERSION")"
   packagename = "%UNIXPRODUCTNAME%BRANDPACKAGEVERSION-dict-xy"
   requires = "%UREPACKAGEPREFIX-ure,%BASISPACKAGEPREFIX%OOOBASEVERSION-core01,%BASISPACKAGEPREFIX%OOOBASEVERSION-core02,%BASISPACKAGEPREFIX%OOOBASEVERSION-core03,%BASISPACKAGEPREFIX%OOOBASEVERSION-core04,%BASISPACKAGEPREFIX%OOOBASEVERSION-core05,%BASISPACKAGEPREFIX%OOOBASEVERSION-core06,%BASISPACKAGEPREFIX%OOOBASEVERSION-core07,%UNIXPRODUCTNAME%BRANDPACKAGEVERSION"
   linuxpatchrequires = ""
   copyright = "1999-2008 by OpenOffice.org"
   solariscopyright = "solariscopyrightfile"
   vendor = "OpenOffice.org"
   description = "Xy dictionary for %PRODUCTNAME %PRODUCTVERSION"
   destpath = "/opt"
   packageversion = "%PACKAGEVERSION"
   End

Add the same name to setup_native/source/packinfo/package_names.txt

   %PACKAGEPREFIX%SOLARISBRANDPACKAGENAME%BRANDPACKAGEVERSION-dict-xy Xy dictionary for %PRODUCTNAME %PRODUCTVERSION

After you defined the package in this way, the last step is the assignment to the product languages. This happens in

setup_native/source/packinfo/spellchecker_selection.txt

You find something similar to this:

   # This file defines the languages of the spellchecker, that are
   # included into the language specific installation sets.
   # First column: Language in the installation set.
   # Second column: Assigned spellchecker languages. Comma separated list.
   
   af = "af,en-US"
   cs = "cs,en-US"
   da = "da,de,en-US"
   de = "de,en-US,fr,it"
   en-US = "en-US,es,fr"
   es = "en-US,es,fr,pt"
   et = "en-US,et"
   fr = "en-US,es,fr"
   gl = "en-US,pt,es,gl"
   hu = "de,en-US,hu"
   it = "de,en-US,fr,it"
   ja = "en-US"
   ko = "en-US"
   lt = "en-US,lt"
   ne = "en-US,ne"
   nl = "en-US,fr,de,nl"
   pl = "de,en-US,pl,ru"
   pt-BR = "en-US,es,pt"
   ru = "de,en-US,ru"
   sk = "en-US,sk"
   sl = "en-US,sl"
   sv = "de,en-US,sv"
   sw = "en-US,sw"
   th = "en-US,th"
   vi = "en-US,fr,vi"
   zh-TW = "en-US"
   zh-CN = "en-US"
   zu = "en-US,zu"

If you want, that your spellckecker in language “xy” is required for installation sets containing language “es”, you can simply add “xy” to the comma separated list for “es”:

Old: es = "en-US,es,fr,pt"

New: es = "en-US,es,fr,pt,xy”

You can add “xy” to as many languages as you like. And if it not already exists, you can also create a new line for language “xy” and define which spellchecker extensions shall be added into installation sets containing language “xy”.

That is all you have to do. Now you only have to build cvs module “scp2” and to deliver “scp2” and “setup_native”. Then you can start creation of installation sets in module “instsetoo_native”.

License for your dictionary

If your dictionary specifies license text, registration of the extension will fail. Extension will be packed into installer set and installed, but will not be registred with unopkg so it will not be visible from OpenOffice.org.

Only dictionaries that do not require user license agreement can be integrated into installation set.

Personal tools