I am still struggling getting LinguaPlone to work.
I have set up two language root folders /de (for German) and /en using /##language-setup-folders. I've created two folders, /de/texte/ and /en/articles and defined the latter as translation of the former.
In portal_languages in the ZMI I have set:
Allowed languages: English, German
Negotiation Scheme: [x] Use cookie for manual override
all other options are unchecked
I do get a language selector rendered, but when I click on "English", which calls /de/texte/switchLanguage?set_language=en, I get an English UI, but the location is still /de/texte.
And even though the breadcrumbs say You are here: Home › texte, Home actually still points to /de instead of /en.
I've searched the web, but apart from some older rant on LinguaPlone I could not find what I've been possibly missing.
How do I configure LinguaPlone to actually load the linked translation when switching languages?
Edit:
Plone 4.0.2
Zope 2.12.13
LinguaPlone 4.0
You have indeed the wrong language selector. There have been recurring reports about this but so far nobody found out why and how it happens. The correct language selector overrides the Plone default one by being defined for the ILinguaPloneProductLayer layer. This browser layer should be active as soon as you have the "LinguaPlone" skins folder as part of your skin layers.
You could try to reorder the skin layers in your theme by going to "http:///portal_skins/manage_propertiesForm" and moving LinguaPlone to the top, right after "custom".
If you have a theme of your own and defined any extra browser layers, those could possibly interfere as well, but it's hard to tell in what exact ways.
I think you have the wrong language selector.
There is a basic language selector viewlet that is shipped with Plone ("plone.app.i18n.locales.languageselector" in plone/app/i18n/locales/browser/configure.zcml). It just switches the language of the Plone interface (not the content). This is the language selector that links to "switchLanguage".
When you install LinguaPlone, it overrides the Plone language selector with it's own.
The LP selector is not supposed to link to "switchLanguage", but the URL of the content item in the target language (with the ?set_language parameter).
This viewlet is defined in Products/LinguaPlone/browser/configure.zcml
Perhaps LP is not correctly installed, or something is overriding the viewlet ?
The reason for this behaviour is that LinguaPlone 4.0 is not compatible with the "Plone Classic Theme" on Plone 4.0.2.
Switching to the "Sunburst Theme" solves the problem: the language selector links point to the correct URIs then.
Related
Whenever i create a contact form in my Joomla! 3.3.6, some script appears in the the page's HTML code that contains many words Joomla in it. I'd like to change those Joomla words and replace them with another words (i.e. Foo) for some security issue. I'd like to know whether or not i'm able to do so and how.
That script is:
<script>(function(){var strings={"JLIB_FORM_FIELD_INVALID":"\u0641\u06cc\u0644\u062f \u0646\u0627\u0645\u0639\u062a\u0628\u0631: "};if(typeof Joomla=='undefined'){Joomla={};Joomla.JText=strings;}
else{Joomla.JText.load(strings);}})();</script>
I have no idea whether a plugin or an extension creates it or not.
Thank you
Regards
This script seems to be translating some text required for the form to use in its javascript, eg validation messages. It does this using a javascript version of JText, which is part of core Joomla. There is some info on how that works here. Weirdly, there seems to be little information in the official Joomla documentation about it.
The main JText function it is calling appears here: media/system/js/core.js
I'm sure it would be possible to write a plug-in to remove this script before the page is rendered and then to translate any untranslated text with your own scripts. However, I'm not sure I see any security benefit in doing this so it seems a waste of time.
Ultimately, someone sniffing a site for what it is built in is far more likely to see if core files exist by going direct to places like media/system/js/core.js, rather than to scan the code for the word "Joomla" - which would trigger a lot of false-positives (any site which just mentions Joomla) and negatives (any page which doesn't have a form on it). It also does not reveal the version of Joomla, which is the info a hacker would more likely be after.
I think you have to search for the script (i.e via Notepad++) in the whole directory. It must be a plugin for the contact form that has some inline script in it.
also do you use any special third party plugin or so? that might be the source of it.
PS: also i had some similar experience, i don't know exactly how i got rid of those words, but like you, i wanted to do that to hide the fact that i'm using joomla for security.
Its actually Joomla who add this, from the file: Joomlainstall/libraries/joomla/document/html/renderer/head.php
And load it globaly from:
Joomlainstall/libraries/cms/html/formbehavior.php
The developer ad that code by using the function, JText, for an example:
JText::_( 'COM_CONTACT_EMAIL_FORM' )
In my case it was the plugin ContactUs Form who add the javascript. If JText is not used, it is not loaded. If I disabled the plugin, the javascript was then not loaded. If you have that plugin enabled, my be try an other contact form?
For security reson it is bad programming by the developer off Joomla, for sure.
I am loading https://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.3 but I'd like to change language dynamically like if I change website language I would change language also in route.Itinerary.Segments[i].Instruction stuff... is there a way?
Thanks everyone!
Cheers
Luigi
You have to use the mkt parameter of the URL to set the culture as documented here: http://msdn.microsoft.com/en-us/library/gg427600.aspx
Note that the v6.3 control is really old and the documentation for it was taken offline a while back (thus the reason for pointing to the v7 documentation above - works for the most part with v6.3). The v6.3 control supports a very small number of languages. You should be using the Bing Maps v7 control which supports a lot more languages and has a lot more features, along with having much better performance.
As for dynamically changing the culture, you can try reloading the map control with a different mkt value by adding a script reference to your page, however this will require you to reload your map as well. Alternatively you can reload the page and change the mkt parameter of the URL using server side code.
While creating a new Portal (dnn 5.6.1) from "portal template" which is created from a bilingual portal(en and tr), all pages(both en and tr) are created in one language. if I activated the second language creates another set of pages for both en and tr pages.
I tried creating a portal template while the second language is disabled but result is same.
do you have any idea to overcome this issue?
My hunch is that, at time of writing, this is an outstanding issue that can't be resolved directly through the UI (I say that because it sounds like you tried every reasonable measure).
If that is the case, your best bet would probably be to edit the generated portal template XML file and remove the elements that represent the second languages pages prior to importing to your target dnn instance. Then you could enable the second language and it would replicate the first language's pages and you could re-localize them. (Hopefully you don't have a ton of pages!).
Alternatively, you could potentially export page level templates for the second language and import them after you've done the import of the portal in the first language. If you take this path, and you have a lot of pages, you may export individually but "bulk import" them by placing them in the /Install/Template folder and hitting the /Install/Install.aspx?mode=installresources URL.
DNN 5.6.1 and i believe also DNN6 has serious issues with exporting/importing multilingual portals. From what i read, the multilingual issue is overcome in DNN 7 which is a major update.
One way to work with legacy multilingual DNN sites is this (far from ideal):
The template which is going to be exported must be in only one language. You may not press the "enable content localization". This is the moment after which export/import becomes very messy.
You export the single language template (this you must keep as the backup point)
Now you import your template.
Then you enable other languages & content localization button (wait till pages are created)
Now you enter the content into the second language pages.
No backups can be created, so you can only backup the content you have entered in the second language, manually..
In any case i recommend you start fresh with DNN7 or a different CMS altogether (WP, Drupal, Joomla...).
I am working on a Drupal site with a few friends. Obviously we can Version control the code... but what do we do to keep each others databases in check?
I have managed to get all the theming into files (contemplate etc), but ideally my views settings, menu settings would be in line also... (Not worried about Content either way as we're just building the framework)
Any suggestions?
Using Features along with Context is very powerful. Context lets you create a "section" for your site. It's best illustrated through an example:
Lets say we define the "Forum" context as anything with the url of forums/*. Context lets us say: "I want to show these three views in the right side bar, only when I am in the "Forums" context.
Now, using Features, we can create "module" define by the context. So, we will end up with a module called "youSite_forums", which will include all the views, blocks, etc. that was define in your Forums context. It also will determine the correct dependencies, as well as Content Types used in the context. All will be bundled up nicely in a module.
As for versioning content such as node, you can user either Node Export, or just do a DB dump using Backup and Migrate. We use these occasionally, but we never have every node versioned in SVN.
Links:
Features
Context
Backup and Migrate
Problem Solutions in Database Migration from Development to Live Sites
You can find some more opinions on this here: Drupal DATABASE deployment strategies?
The home page for DotNetNuke 5.2 is around 252.6KB. It uses 15 JavaScripts and 8 CSS files. The number of resources DotNetNuke uses seems excessive to me. I am looking for best practices creating DotNetNuke skins that limit the JavaScript and CSS resources.
You can use the Unload CSS Skin Object to remove links to some of the CSS files loaded by the framework (like Default.css, portal.css & any module-specific CSS files). You can then move all of those styles into the skin (or portal stylesheet, whichever is your preference), so that there's only one stylesheet that gets loaded.
I don't know of any solutions for combining JavaScript resources or reducing the number of scripts that DNN requires.
From 6.1 onward, the Client Resource Management component is the solution for this. It automatically combines all your files, cleaning them up, removing comments, and minifying if desired.
http://www.dotnetnuke.com/Resources/Wiki/Page/Client-Resource-Management-API.aspx
It takes a little getting used to, but the control is quite nice. You can decide which order they'll go in, you can group the files in bunches if you don't want one big single file - maybe you want certain bunches of scripts together but not all.
One thing to remember is that when you're doing development (as noted by the comment below, which I've since edited this post), you should always use debug=true in the web.config, otherwise if you are using Resource Mgmt and change your source files, you'll constantly need to regenerate the combined files by going into Site Settings, Client Resource Management, and increment the version. It's kind of a protection to keep anything from altering your clients' browser caches without intent (that's the message box that pops up to let you know when you do it). I'm sure if you have a zillion users this might make a difference.
Part of that is just the dynamic nature of DNN - there are some good resources that R2i has published about combining javascript and CSS
One concrete suggestion is to combine all your skin and contianer css in one file and if you have full control of the site to combine the css from the modules you use into that same file.
I know with the addition of the Telerik controls there is some abilities to combine resource files
Another thing that helps is to combine graphics into a single file and use CSS (the sprite technique) to cut down number of files loaded and calls to the sever
Like it was stated above, it's the nature of the beast. Each module will have at least 1 css file included. You can check out PageBlaster from snapsis.com, I believe it will do what you are looking for.