I have following question
Item level Fallback is enabled in “Sitecore.LanguageFallback.config” and fallback/default language is “en”
Languages configured in site : en, de, el, es, fr, it, ja, pt, zh
Scenario: We try to access the site with Russian(ru) or any other language which we have not configured in sitecore . The site still loads without any error, but no contents are fetched, as the language is not configured the fallback to English language doesn’t working.
Does sitecore loads the page for all the valid languages available irrespective of languages we configure under system/languages. If Yes, then should we explicitly handle in our code to restrict this behavior or fallback to English? Or is there a way we can handle this through configuration.
This is the expected behaviour unfortunately, Sitecore will load for all languages regardless of whether you have them enabled/configured in the CMS.
You need to handle this yourself in code. On possible option is to use a similar processor to this by John West and override the StripLanguage processor.
public override void Process(PreprocessRequestArgs args)
{
if (args != null
&& args.Context != null
&& !string.IsNullOrWhiteSpace(args.Context.Request.FilePath))
{
string prefix = WebUtil.ExtractLanguageName(
args.Context.Request.FilePath);
if ((!string.IsNullOrWhiteSpace(prefix))
&& !this._validLanguages.Contains(prefix.ToLower()))
{
return;
}
}
base.Process(args);
}
By simply not stripping out the language code when interpreting request URLs, Sitecore will try resolve the item it will not find a matching ru item under your home and therefore throw as 404 as you would expect it to. (You could also redirect the user to the default language at this stage instead).
The slight down side to this is that the languages are specified in config and any changes would require a deployment. Depending on your exact requirements, you could read these in from an Item specified in the Sitecore tree if you require it to be more dynamic.
Your language fallback is not setup correctly. Read the manual at the Sitecore site.
To have a Russian version falling back to English, you need to create a Russian language (it will appear in the Languages list as in your screenshot). On that item, you can fill the Fallback Language field. Set that to English. This defines the fallback language.
In order to have your items use the item fallback (which is what you want if you don't want to create versions in Russian) you must enable that on your items. The easiest way to do so is set it in the standard values of the templates. The checkbox Enable Item Fallback must be checked for the fallback mechanism to work.
Related
I'm using Sitecore 8.0 Update 5.
Each time I'm doing a "Smart" publish with languages other than English I can see that thousands of items being updated.
Job started: Publish to 'web'
Items created: 0
Items deleted: 0
Items updated: 56207
Items skipped: 13057
Job ended: Publish to 'web' (units processed: 69258)
I've enabled tracing and in the logs I can see that Sitecore updateds shared fields of those items
##Publish Item: Name=sitecore, Uri=sitecore://master/{11111111-1111-1111-1111-111111111111}?lang=zh&ver=1, Operation=Updated, ChildAction=Allow, Explanation=Shared fields were published.
##Publish Item: Name=templates, Uri=sitecore://master/{3C1715FE-6A13-4FCF-845F-DE308BA9741D}?lang=zh&ver=1, Operation=Updated, ChildAction=Allow, Explanation=Shared fields were published.
##Publish Item: Name=List Manager, Uri=sitecore://master/{D2833213-CB77-431A-9108-55E62E4E47FD}?lang=zh&ver=1, Operation=Updated, ChildAction=Allow, Explanation=Shared fields were published.
And the list goes on like that for pretty much every item in the tree.
Armed with dotPeek I was able to find a method in publishing pipeline that is responsible for determining publish action:
private void HandleSourceVersionNotFound(Item sourceItem, PublishItemContext context)
{
Assert.ArgumentNotNull((object) sourceItem, "sourceItem");
Item targetItem = context.PublishHelper.GetTargetItem(sourceItem.ID);
if (targetItem != null)
{
Item[] versions = targetItem.Versions.GetVersions(true);
if (versions.Length > 0 && versions.Any(v => v.Language != sourceItem.Language)) || Settings.Publishing.PublishEmptyItems)
context.Action = PublishAction.PublishSharedFields;
else
context.Action = PublishAction.DeleteTargetItem;
}
else if (Settings.Publishing.PublishEmptyItems)
context.Action = PublishAction.PublishSharedFields;
else
context.AbortPipeline(PublishOperation.Skipped, PublishChildAction.Skip, "No publishable source version exists (and there is no target item).");
}
Here we can see that it checks item versions and if there are versions on language other than English it sets action to PublishAction.PublishSharedFields.
Settings.Publishing.PublishEmptyItems is set to false in my case, so this should not trigger shared fields publish.
I thought that the only "system" items with non-English version in my solution were languages, but when I looked on one of the item from the logs I discovered a really interesting thing:
Sitecore default languages
These appears to be Sitecore "default" languages.
This behavior causes a performance problem with publishing when I enable Language Fallback module. (https://marketplace.sitecore.net/en/modules/language_fallback.aspx)
My questions are:
Is this an expected behavior for Sitecore to push shared fields each time when you publish?
Is this an expected behavior for Sitecore to push shared fields on system items when they have versions only on these default languages?
How can I disable those default languages and remove versions on these languages? (Powershell?)
What are the implications of removing these default languages?
Is there anything that I'm doing wrong that can cause this kind of behavior?
UPD. On a different environment where it goes over 100k items threshold and triggers full index rebuild, which is pretty expensive operation. (With or without language fallback)
Thanks in advance!
How can I disable those default languages and remove versions on these languages?
If the language is registered under /sitecore/system/Languages, Sitecore should remove all item version, for the language, if you remove the language.
If the language is not registered (or Sitecore, for some reason, fails to remove it when you remove it) under /sitecore/system/Languages, do a database cleanup (Control Panel > Database > Clean Up Databases). Sitecore will remove any version of items that are in a language that is not registered.
What are the implications of removing these default languages?
Unless you plan on using those languages in the future, no real implication.
Is this an expected behavior for Sitecore to push shared fields each time when you publish?
=> No but the code you've found isn't used for every item. That action occurs when the Source Version isn't found ea the item exists in web but not in master. That's why it's either publish shared fields (in case other versions do exist) or delete the item completely from web (because it no longer exists in master).
Is this an expected behavior for Sitecore to push shared fields on system items when they have versions only on these default languages?
=> I'm unable to answer this question as is without deeper investigation for which I do not have time at this point I'm sorry.
How can I disable those default languages and remove versions on these languages? (Powershell?)
=> These languages aren't registered, they're showing up because these items do have a version in those languages. So if you remove the versions of all system items in those languages they'll no longer show up. You can create a version in any language even a non-existing one through code.
What are the implications of removing these default languages?
=> Any content editors that are using that language might suddenly see english (or a leftover language) instead of their preferred set Sitecore Editing language. Beyond that it should not matter.
Is there anything that I'm doing wrong that can cause this kind of behavior?
=> Not that I can see from what you've presented thus far.
I am currently working with sitecore items that are in a draft workflow state. The following happens:
Create an item that will go into workflow draft state
Publish the item/publish the parent item (with sub items selected) to the web db from master db, ignore publish warning prompt
The item will appear in the web database but with no versions
This causes our controls to render the item but with standard values because there are no versions. Of course we could add a check for item.Versions.Count > 0 but my question is why this is happening?
Surely an item in draft workflow state should never appear in the web database in any way?
The workflow being used is pretty standard and has no customisation. The states and commands are:
Draft
Submit
Awaiting approval
Reject
Approve
Validation action
Approved
Auto publish
Thanks in advance.
I believe you can use the following property on each of your site nodes in the config.
<site name="website" filterItems="true" ... />
If setting this to true doesn't resolve the issue then you can add the following pipeline step, in addition to the above setting, before the Sitecore.Pipelines.FilterItem.EnsureFilteredItem step.
public class HideEmptyItem
{
public void Process(FilterItemPipelineArgs args)
{
if ((Context.Site != null && Context.Site.DisplayMode == DisplayMode.Normal) && args.Item.Paths.Path.StartsWith("/sitecore/content/"))
{
try
{
Context.Site.DisableFiltering = true;
if (args.Item.Database.GetItem(args.Item.ID, Context.Language).Versions.Count == 0)
{
args.FilteredItem = null;
}
}
finally
{
Context.Site.DisableFiltering = false;
}
}
}
}
Also ensure the following is set accordingly, the default is false;
<setting name="Publishing.PublishEmptyItems" value="false" />
I actually encountered this issue but in a different way. If you use publishing restrictions you can end up with an item that has no versions on it but can still be published. There are many ways for an item to end up with no versions, not just a new item with a single version that hasn't been pushed through a workflow. The above fix was actually provided by Sitecore support and worked for me.
If this doesn't work for you then I would suggest adding in check when items are published to see if they have any versions, although I believe that's what the fix above is supposed to do.
EDIT: Changed property from "hideEmptyItems" to "filterItems" and added further explanation.
My personal opinion is that you should be checking for version count. If you plan on ever supporting a multilingual site, it is entirely possible to have a version in one language, but not another (not approved yet in Spanish, for example). You would want your controls to handle that scenario (or execute fallback).
It is entirely valid that the current user in the current language may have no valid versions come back for them. I would expect that the business logic of the web controls should handle those scenarios.
To explicitly answer your question, this happens because the item is not null but it has no versions. A version is a dimension of an item and it happens to be "empty" if you have no version. So your code gets a valid non null item, but has no field values since there is no version and thus your controls don't fill with data.
This will only happen for new items. Example: create an item and you have v1 which is is in draft. You "publish" the item. The item goes out to the web DB but the v1 dimension of it does not, so you're left with a non null item with no versions.
As Jay said, the solution is to check for this when you query items.
First, the default workflow should set to the item's template "__Standard Values".
Second, workflow with "admin" account doesn't work. Try another account.
In Rails 4 (which supports multilingual inflections), I can set:
config.i18n.default_locale = :es
in my config/application.rb, which allows me to do stuff like this in the console:
'general'.pluralize(:es) => "generales"
But when I run:
rails g model General conciencia:string atencion:string
Rails generates files with 'general' pluralized as 'generals' which in spanish should be 'generales'
Shouldn't Rails be using the multilingual inflector for its generators if the locale is set? Is there a way to force it to use them?
Thanks!
A bit late, but for the record: There's an argument in a Rails issue about why is it this way (so it's no a bug, but you can discuss it about):
Source: https://github.com/rails/rails/issues/10125#issuecomment-17274499
Up to Rails 4, the inflector had no support for multiple locales.
There was only one set of rules. The application has a default locale,
and in a i18n application each request may have a different locale,
but that didn't affect the inflector.
The inflector is not only used by the application, it is also used by
the framework to convert paths to class names, class names to tables,
create method names dynamically for the associations API, etc.
Obviously, those computations cannot vary. If your schema has a
"regions" table, Active Record has to map the Region class always to
the "regions" table, no matter the evolution of the application
(unless the schema changes, but the schema has to be visualized as
mostly static regarding to this, much more static that a configuration
option).
I have worked on applications that started development using :en, get
i18ned, and then switch to a default locale of :es. The locale is
something that affects the interface in that mindset. Everything
internal should work as it did before.
You should be able to change the default locale and everything else in
a way that does not affect static things like association names,
tables, routes, etc.
In could be the case that you have i18n routes (which change with the
locale of the request), but in general the statement above should be
true.
In order to be as backwards compatible as possible, we have left the
framework untouched, and have made the inflections to have a default
of :en so that existing applications get the same mappings after an
upgrade.
I have an application where elements are added to the page dynamically and I want screen readers to read them for different versions of browsers ( IE 8/9/10, FF and Chrome).
What's the difference between the following two: adding a 'role=alert' attribute Vs 'aria-live=assertive'?
$("<div role='alert'>Sample message.</div>").appendTo($existingElement);
$("<div aria-live='assertive'>Sample message.</div>").appendTo($existingElement);
By default, role='alert' inherits aria-atomic and aria-live with an assertive value, so should behave similarly from a user's perspective. However, not all user agents implement specifications in the same way.
The w3c recommends that you use an appropriate role when available, in preference to a generic aria-live region. This comes with the caveat that user agents have historically shown inconsistent behaviors between the two.
Testing against HTML5 Accessibility's alert test page demonstrates that ChromeVox 1.27.0 supports the technique you showed, while VoiceOver on OS X 10.8.4 with Safari does not.
I am working on a django website/project, it has already been internationalised/localised to us-english, gb-english and mandarin.
It is deployed with same codebase except for the settings config which states what lang to use. Some deployments are mandarin only, others are us-english.
The client now has a requirement to change some of the language used within a gb-english version for a specific deployment. My main goal is not to duplicate things and I think I can get what I need out of django 18n.
Basically, I am looking to find if i can or should use django i18n to handle:
'Welcome' on deployA
'Oh hai' on deployB,
even though they're still both gb-english based sites, I feel I should be able to say that deployA will use 'en_GB' and deployB would use 'en_GB_special'.
I suppose it's the fact that I want to use a non-standard i18n name/code that is making me wonder if I should do this, or if I am approaching this in the wrong manner.
I would only create a new language if you're intending to maintain two translations. If the new site will need to stay in sync with en_GB and/or you intend to use the customization in another language then I think you'd be better off creating new messages, adding a string for them to en_GB and add a flag to your application to switch the feature for your feline client.