Is there a way to limit SugarCRM to just one language (us_en)? Right now everything we do generates 40+ language files which we'll never use. It makes finding things in the folders very difficult.
After removing all the languages except en_us my /sugarcrm/config_override.php contains the following:
<?php
/***CONFIGURATOR***/
$sugar_config['disabled_languages'] = 'bg_BG,cs_CZ,da_DK,de_DE,el_EL,es_ES,fr_FR,he_IL,
hu_HU,hr_HR,it_it,lt_LT,ja_JP,ko_KR,lv_LV,nb_NO,nl_NL,pl_PL,pt_PT,ro_RO,ru_RU,sv_SE,
th_TH,tr_TR,zh_TW,zh_CN,pt_BR,ca_ES,en_UK,sr_RS,sk_SK,sq_AL,et_EE,es_LA,fi_FI,ar_SA,uk_UA';
/***CONFIGURATOR***/
I then created test with a new package, named Dan, which has one module named Pets. When I look in version control I still have a file for each available language in the sugarcrm/custom/modulebuilder/packages/Dan/modules/Pets/languages
It seems you can accomplish that by modifying the language array in the sugar config.
Make sure to make a backup of your config.php, so that you have the original language array if you need it back. This is important even although our change will be in another file, because Sugar might recreate config.php automagically, using the resulting array, losing the original one.
In your config_override.php add this line:
$sugar_config['languages'] = array('en_us' => 'English (US)');
Be aware that above line will make 'en_us' the only available language on that instance and Studio/etc. should now only create en_us files. If that is not the solution you're looking for - let me know please.
EDIT:
Above steps only seems to disable file creation spam for Dropdown Editor.
If you also want to make Module Builder not create any non-en_us language files, I found this - quite invasive - method of accomplishing just that:
Create a Backup of the instance, then remove all *.lang.php files from the directories of include/ and modules/, except for en_us.* files. On Linux you can do this with find include modules -name '*.lang.php' -not -name 'en_us.*' -print -delete
Delete the contents of the cache/ folder
In Sugar run Administration -> Repair -> Quick Repair and Rebuild
This made my Module Builder only create en_us language files.
Note: If anybody should ever consider doing this for any other language than en_us, make sure to not only keep your language of choice, but also keep the en_us files additional to that! Those files are expected to exist in Sugar, as they are e.g. used for fallbacks of missing strings in any other language. Deleting the en_us files may lead to unexpected side-effects!
Related
I am trying to setup fulltext search for Czech language. I am little bit confused, because I see some cs_cz.affix and cs_cz.dict files inside tsearch_data folder, but there is no Czech language configuration (it's probably not shipped with Postgres).
So should I create one? Which dics do I have to create/config? Is there some support for Czech language at all?
Should I use all possible dicts? (Synonym Dictionary, Thesaurus Dictionary, Ispell Dictionary, Snowball Dictionary)
I am able to create Czech configuration for ispell dict and it works fine, bud I am not sure if it's enough (just ispell configuration).
Thanks a lot I tried to read https://www.postgresql.org/docs/9.5/static/textsearch.html but I am little bit confused.
I have never tried it, but you should be able to create a Czech Snowball stemmer as long as you are ready to compile PostgreSQL from source.
There is an explanation in src/backend/snowball/README:
The files under src/backend/snowball/libstemmer/ and
src/include/snowball/libstemmer/ are taken directly from their libstemmer_c
distribution, with only some minor adjustments of file inclusions. Note
that most of these files are in fact derived files, not master source.
The master sources are in the Snowball language, and are available along
with the Snowball-to-C compiler from the Snowball project. We choose to
include the derived files in the PostgreSQL distribution because most
installations will not have the Snowball compiler available.
To update the PostgreSQL sources from a new Snowball libstemmer_c
distribution:
Copy the *.c files in libstemmer_c/src_c/ to src/backend/snowball/libstemmer
with replacement of "../runtime/header.h" by "header.h", for example
for f in libstemmer_c/src_c/*.c
do
sed 's|\.\./runtime/header\.h|header.h|' $f >libstemmer/`basename $f`
done
(Alternatively, if you rebuild the stemmer files from the master Snowball
sources, just omit "-r ../runtime" from the Snowball compiler switches.)
Copy the *.c files in libstemmer_c/runtime/ to
src/backend/snowball/libstemmer, and edit them to remove direct inclusions
of system headers such as <stdio.h> – they should only include "header.h".
(This removal avoids portability problems on some platforms where <stdio.h>
is sensitive to largefile compilation options.)
Copy the *.h files in libstemmer_c/src_c/ and libstemmer_c/runtime/
to src/include/snowball/libstemmer. At this writing the header files
do not require any changes.
Check whether any stemmer modules have been added or removed. If so, edit
the OBJS list in Makefile, the list of #include's in dict_snowball.c, and the
stemmer_modules[] table in dict_snowball.c.
The various stopword files in stopwords/ must be downloaded
individually from pages on the snowball.tartarus.org website.
Be careful that these files must be stored in UTF-8 encoding.
Now there is a Czech Snowball stemmer available here, it was contributed to the project. There is no stop word dictionary available, but I am sure you can either find one or create one yourself.
The real work would be to install Snowball and use the Snowball-to-C compiler to create the C and header files to add to the PostgreSQL source.
These files should then remain stable, so it shouldn't be difficult to upgrade to a new PostgreSQL version.
If you are willing to do the work, but don't want to patch PostgreSQL and build it from source every time, you could also consider submitting a patch to PostgreSQL. As long as the stemmer works fine, I don't expect that you will much resistance there (but the patch submission process is still tedious).
I have a custom PowerShell module with a corresponding module manifest. In one command in my module I have a hard-coded array of hash tables. This was fine at first but occasionally I have to go back and add new hash tables to this hard-coded array and the array is becoming quite long. It is becoming difficult to manage this data in this way. What I would really like to do is move this collection out into an external resource (e.g. a CSV file) and have the command read the data from the CSV file. Actually, this is what I preferred from the beginning but it has only just now become painful enough that I feel compelled to figure out how to do this.
My question is how would I go about doing this? Or can it even be done? I have read quite a bit about module manifests but I do not ever recall reading anything that describes a way to specify additional resources in the manifest file or how to load those resources in such a way as to be 'private' to a module. I suppose I could just drop the CSV file in the module's folder with all the other PowerShell files and then maybe I can find it using $PSScriptRoot but that does not seem very 'official' (and I am not 100% sure it would work). Plus, by doing it that way there is nothing in the manifest that would suggest to somebody else that there are other resources that are required for the module to function properly.
Is there a best practice for something like this or am I coming at this all wrong?
The manifest definition does have a key for this; it is called FileList and is essentially an array of files. Since the description generated by the New-ModuleManifest cmdlet says, "List of all files packaged with this module," that is what I specified when I used it. (I didn't have to list the .psm1 file since it is listed elsewhere in the manifest.)
# List of all files packaged with this module
FileList = #(
'script1.ps1',
'script2.ps1',
'Microsoft.Web.Publishing.Tasks.Dll',
'transform.proj',
'some_file.xml'
)
As for locating the files, I simply use $PSScriptRoot, just like you suggested.
To my knowledge, there isn't anything that automatically handles installation of the module. It's still up to you to get it into a folder in the PSModulePath environment variable.
I have a PHP project in NetBeans
I have a constant named KEY and I want to change it to SECURE . This constant is spread through out many files of my project. How can I approach this very quickly. I've heard of refactoring, and even tried it but it only renamed the current file and not the whole project's files.
Use Ctrl+Shift+H, after clicked on project folder. Lower in dialog you may specify all needed params. As far as it's a constant, you may prefer to specify case match, or if needed, use regular expressions
I have a custom package that I find myself reusing repeatedly in Dymola models, and I'd like to put this package in a common directory that is automatically loaded whenever I start Dymola. My current strategy is to load the custom package when a model I'm working on is loaded and then save total. This is not elegant because the contents of the custom package end up saved in multiple locations across my hard drive, and if I change one of them, the changes are not reflected everywhere. I would like a more robust way of distributing this custom package to all of my models. Is there a way to tell Dymola to automatically load my custom packaged every time?
The trick is to add the following lines to settings.mos in c:/Users/USERNAME/AppData/Roaming/Dynasim:
Utilities.setenv("MODELICAPATH", "C:\Users\USERNAME\Documents\Dymola");
openModel("c:\Users\USERNAME\Documents\Dymola\UserDefined\package.mo")
The first line adds the directory to the path that Dymola uses to search for packages that have not been loaded prior to the first run of a model, and the second line loads the specified package. These two commands may be somewhat redundant, but I am doing both because I want to make sure my custom packages are on the path in addition to loading the UserDefined package.
Two suggestions. First, you need to add your package to the MODELICAPATH. You'll have to consult the Dymola documentation to figure out exactly what you need to do. But normally, what this means is that you have to set an environment variable that gives a list of directories (; separated) to be searched for your package. Now that will put it in your path so it can find it automatically, but it won't load it until it needs it.
If you want it to always appear in the package browser, you'll probably need to set up a .mos file (script) to load it. Dymola has that capability, but you'll have to read the manual to figure out what that script has to be called and where Dymola expects to find it.
I hope that helps.
In the instalation folder of Dymola 2018 -> insert -> dymola.mos
I've added the lines:
Utilities.setenv("MODELICAPATH", "C:\Users\XXXX\Documents\Dymola");
openModel("C:\Users\XXXX\Documents\Dymola\DCOL\package.mo");
openModel(“C:\Users\XXXX\Documents\Dymola\Annex60 1.0.0\package.mo”);
Now I don't get the utilities sentence, as the DCOL package loads fine without it and the added 'utilities' package in the package menu is useless.
But it does not open the Annex60 package.
I've tried a lot of different combinations and can't get multiple packages to load. I doubt that "cd" and "Advanced.ParallelizeCode", which are also added in the text work.
The accepted answer does not work since Dymola 2017 FD01, as the file settings.mos is not used anymore. User settings are stored in the setup.dymx file instead, located in
C:\Users\USERNAME\AppData\Roaming\DassaultSystemes\Dymola
In contrast to the setup.mos file you can not include custom lines with modelica script in setup.dymx.
The answer using dymola.mos still works, but you need admin privileges to modify this file.
Here is a simple solution which works with all Dyomola versions:
You can pass a .mos-script as first parameter to the dymola.exe.
This can e.g. be done like this:
Create a .mos script somewhere with commands like openModel(), etc.
Create a desktop shortcut to Dymola.exe
Open the properties of the shortcut and add the path to the .mos script in the Target text field. It will then look something like this:
"C:\Program Files\Dymola 2018 FD01\bin64\Dymola.exe" "C:\<some-path>\startup.mos"
Start Dymola with the desktop shortcut. The script will be executed and eventual errors or messages are displayed in the Commands window
Another suggestion where you don't need to hardcode your package into an environment variable of your operating system (and maybe more safe for inexperienced programmers):
Go to the folder where Dymola is installed (e.g. C:\Program Files\Dymola 2020).
Search for the Dymola.mos file in the insert-folder. 'insert' folder
Open the script (e.g., in notepad++)
Add the link(s) to your Dymola-library-package.mo file(s) here with the openModel statement
e.g., openModel("C:/IDEAS/package.mo"); Dymola.mos script
Save the script. Now, every time you open Dymola, your libraries will be loaded automatically.
I need to refer to Doxygen documentation pages. The file names however are not stable as they change after every generation. My idea is to create a symlink to each HTML file created by Doxygen , having a stable and human friendly name. Have anyone tried this?
Actually, it might be very easy just to parse the annotated.html file Doxygen produces. Any documented class shows up there as a line like:
`<tr><td class="indexkey"><a class="el" href="dd/de6/a00548.html">
ImportantClass</a></td>`
The hard problem for me is that I would like to have my file names (i.e. the symlinks) be visible on my server like:
http://www.package.com/com.package.my.ImportantClass.html
[Yes, the code is in java]. So the question actually reads: "how to connect a HTML page by Doxygen with the right java class name and its package name.
You seem to have SHORT_NAMES enabled, which will indeed produce volatile names. When you set SHORT_NAMES to NO in the configuration file (the default), you will get longer names, but these are stable over multiple runs (i.e. they are based on the name, and for functions also on (a hash of) the parameters.