I have a zope instance with many plone sites each for different customers. I want override particular translations such as the date format just for a single plone site without affecting the others. How do I do this?
Tutorials such as http://maurits.vanrees.org/weblog/archive/2010/10/i18n-plone-4#overriding-translations seem to indicate custom translations override all sites on a zope instance.
This is how I solved it. It's a bit of a hack solution but it worked for my particular scenario.
As per http://maurits.vanrees.org/weblog/archive/2010/10/i18n-plone-4#overriding-translations I
created my own locales package.
overrode the the plonelocales domain just for one particular language variant, in this case en_AU.
loaded the package in zope via buildout with particular attention to make sure it's the first ZCML slug (not instructions in the blog post incorrectly state it must be the first package in the egg section. This wasn't enough to make it work for me).
for each site I wanted to switch date formats I went to site setup > Languages and switch the language to "English (Australian)".
The other gotcha is that when releasing and deploying your locales package make sure that you've
generated the the .mo file first (done for you if you run zope locally)
and you've used an MANIFEST.in file to tell setuptools to include all .mo files as you shouldn't put .mo files under source control and by default setuptools only includes files under source control.
This does not get me a custom date format for every single site but good enough if the custom date format you want is actually that of the language variant you choose to use.
You can implement your own zope.i18n.interfaces.ITranslationDomain utility which looks up translations in a different place. The normal translation domain utilities stores a list of gettext message catalogs. Those are loaded from mo files on the file system and registered with ZCML.
But you can implement a different translation domain, store it as a persistent utility per site and give it some additional storage to look up messages in.
Related
I have the following WebSphere Liberty file layout (with a few choice directories and files show) which uses a custom usr dir of wlp-usr.
wlp/etc/server.env
wlp-usr/servers/server1/apps/
wlp-usr/servers/server1/extension/
wlp-usr/servers/server1/resource/
wlp-usr/servers/server1/bootstrap.properties
wlp-usr/servers/server1/jvm.options
wlp-usr/servers/server1/server.xml
wlp-usr/servers/server2/apps/
wlp-usr/servers/server2/extension/
wlp-usr/servers/server2/resource/
wlp-usr/servers/server2/bootstrap.properties
wlp-usr/servers/server2/jvm.options
wlp-usr/servers/server2/server.xml
The file wlp8554/etc/server.env contains
WLP_USER_DIR=/home/me/wlp-usr
I want to get the servers (there will be more than 2) using their own extension folders, rather than the default wlp-usr/extension/lib.
The documentation on Liberty directory locations and properties suggests that usr.extension.dir is what I want. http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.wlp.nd.doc/ae/rwlp_dirs.html?cp=SSAW57_8.5.5%2F1-3-11-0-2-3
I have tried setting this in bootstrap.properties and jvm.options, but without success. I am wondering if this is a read only property or if it is something that I can actually set. Has anyone used separate extension directories before? Is this even possible? If so then some guidance on how would be most appreciated.
Cheers, Steve
The usr/extension directory is per-user-directory, so it is effectively read-only from a server perspective (all the variables on that page are derived and cannot be changed except wlp.user.dir, which can be set by WLP_USER_DIR, and server.output.dir, which is derived from WLP_OUTPUT_DIR). That is, it is not possible to have per-server extensions. If you really need that capability for some reason, then I would recommend opening an RFE.
That said, usr/extension is really intended for convenience during feature development (or perhaps for minor deployment scenarios). Product extensions are really intended to be applied to an entire installation, so they should probably be used for any sophisticated environments. Since individual servers are unaffected by extension features unless they enable them, there should not be much reason to have per-server extensions anyway.
My application is to be written using wxWidgets, but the question may be related to using gettext in general.
For the application named app, some sources suggest I sould create <lang>/ subdirectory, create the app.po file inside with the translation, and convert it to the distributed app.mo file in the subdir.
Another approach is to create app.pot (i.e. the template from the sources via xgettext), and to msginit and msgmerge it to the <lang>.po for the language.
For the first approach, more .mo files can be put inside the <lang>/ subdirectory. Also the wxLocale::AddCatalog() gets the domain name (where the domain can naturally be app, wxstd, etc.). On the other hand, the <lang>.po file name is descriptive on itself -- wherever it is located.
What are the pros and cons of the two approaches? Is there any text that explains the path to be chosen?
Thanks for your time and experience,
Petr
The Unix convention is to use app.mo for binary catalogs, see the contents of /usr/share/locale directory. Sometimes lang.po is however used for the source ones, as done in wxWidgets itself (see its locale subdirectory), but they're still installed into language-specific subdirectory using the app-dependent name.
I have many bundles (let's say hundreds) and it is quite difficult to specify relation between bundles+features-distrubutions in UI. Image, at first I define all relations between bundles, features and distribution. Than I want to update some bundles... it is almost impossible to find them in current implementation of UI. They are not groupped and one list of all bundles without any search bar is really hard to work with.
Is there any support for a file based solution. For example Apache ACE would watch a certain folder containing distribnution's bundles. When ever I make a change there, it would be propagate it to all targets.
There is currently no file based solution that matches what you describe, however, I think there are still a couple of solutions that might help you:
There are two types of associations between artifacts and features in ACE: static and dynamic ones. The latter can be of help to you, as they always automatically bind to the highest version of a bundle. So, once you've made all your associations, you can simply upload a set of newer bundles and the associations will adapt.
There is also a REST API you can use to programmatically talk to ACE. You can use that to further automate your process.
That said, you have a valid point that it is difficult to keep an overview when there are a lot of artifacts in the first column. I would advise you to watch, or even contribute to the following issues that were all created to improve this situation:
https://issues.apache.org/jira/browse/ACE-319
https://issues.apache.org/jira/browse/ACE-320
https://issues.apache.org/jira/browse/ACE-321
There seems to be two styles of folder structure in the core Magento when it comes to resources. There are quite a lot using the mysql4 folder and other simple using Resource folder.
I.e. install script would live here: Mycompany_Mymodule_Model_Resource_Setup.
Is there a reason for this, legacy or otherwise - or is this simply a coding style between different core developers?
First: Magento's folder structure exists only because of its autoloader's implementation. If you try to derive too much meaning from where a file is placed in Magento you'll go mad, and different modules seem to follow different conventions. The autoloader will look for
Mage_Core_Model_Foo_Bar
in
Mage/Core/Model/Foo/Bar.php
So I'll be talking about naming conventions below, which will indirectly address why a file is in a particular folder.
Originally all database resource were named with the Mysql4 convention. I've talked to a few of the original developers, and the intention was to denote that the resource was for the then "standard" Mysql 4 database. If a resource used a specific feature of say, Mysql 5, then they'd have used a Mysql5 convention.
As Magento Inc. went through the usual startup churn and other developers took over where the original developers left off, the thinking changed on this. The Magento 1.6 release, which laid the groundwork for Enterprise Edition's support of multiple RDBMS, altered how these resources worked and were named.
Backwards compatibility was maintained, but most of the old Mysql4 resources were renamed to use the generic Resource, and a new method for multiple RDBMS support was introduced.
I am looking to clean up the file that we store in source control (SVN) for the Magento projects we are working on.
Which files/folder are have no purpose being in SVN, ie the ones are not necessary for the site to function, or are only transient?
So far I have identified
var\cache
var\session
media\temp
var\locks
downloader\pearlib\download
downloader\pearlib\cache
There are some I am unsure about:
var\report
downloader\pearlib\docs
media\catalog\product\cache\
Can anyone provide a definitive list?
http://activecodeline.com/git-ignore-gitignore-file-for-magento-project answers a larger question, but could be helpful none-the-less.
There's a whole bunch of stuff in Magento that doesn't need to be in source control, as it will remain constant (as long as you follow some sane development practices.) The above link goes through all the directories that need not be tracked by source control.
I typically ignore these folders for development, but you may choose to store images if you think it's appropriate:
/var: This is always temp data or data that can be regenerated
/media: These are images and uploads, not really source code, but keep if you want
/downloader: I don't like to use Magento Connect and prefer to install things manually. You can always get Magento Connect elsewhere, so no need to keep it in the repo.
/includes/src: This is compiled source code, you can regenerate if needed. Not really that usefull since we have SSD disks and APC.
We usually have something like:
/app/etc/local.xml
/downloader
/var
/media
Media usually contains images that are configured in admin, like product/category images, logos, CMS images, merged JS/CSS and import/export data I believe.
Some extensions also have files in media that should be versioned (ex. product feed templates)
There is also an htaccess file in var and media so you have to include those.