1

I read various Composite discussions regarding designing websites not only for multilingual scenarios but also to support localizing volcabulary and grammar for a specific community; for example, technical vs. general public communities.

I found these discussions compelling however they didn't explain how to implement these scenarios in the context of C1 for adding different "dialects".

I am guessing that these dialects should be manually added to the following data source file and treated like a language: "Composite.Cultures.en-us".

Please explain if there is a best-practice for handling the above scenario and if there is a less manual method for achieving it.

Pauli Østerø
  • 6,878
  • 2
  • 31
  • 48
Kevin
  • 45
  • 4

2 Answers2

1

Im not sure if i understand the question. Is it because you want to have a certain string on your frontend website to say different things depending on who is logged in, and not in which language the site is being shown?

Default localization-files in C1 is located in ~/Composite/localization in the format Some.Namespace.language.xml. This means, that if your site is in American English, but you want to show different versions of certain strings for Techs or Others, you could create the following xml-files

  • My.Component.General.en-us.xml
  • My.Component.Technical.en-us.xml

And when you need to get strings to show, you would have the following logic

var ns = "My.Component";
var mode = is_tech ? "Technical" : "General";

return StringResourceSystemFacade.GetString(ns +"."+ mode, "title");
Pauli Østerø
  • 6,878
  • 2
  • 31
  • 48
1

If you want to show different content with in the same page structure for different "dialects", then yes - treating them as languages make sense. The list of languages is fetched by the system from Windows registry, so if you want to add a dialect as a language, you can register it in with some code ( http://msdn.microsoft.com/en-us/library/ms172469.aspx ). I wouldn't recommend it though, as the related ASP.NET process would have to have access to windows registry, and there may be some additional work each time you need to move the site to a new environment.
You can also use an existing culture code that you aren't going to use as a dialect switcher F.e. en-US / en-GB / en-AU.

Another alternative would be to have separate placeholders for content on each page, one for technical users and one more for non-technical. One or another will be shown depending on url/cookie. In this approach you also you have to decide if if you want to keep them under the same url for crawlers or under different, should pages have the same comments or separate, etc.

If dialect sites aren't keeping the same page structure, you may also decide to have them as different page trees, and use some kind of a meta data field to link related pages one to another when you need to.

Dmitry Dzygin
  • 1,258
  • 13
  • 26
  • eh, that makes no sense... you should accept the answer that is correct! – Pauli Østerø Jan 14 '12 at 12:39
  • I am looking for official guidance from Composite A/S - they are suppose to be monitoring the [Composite C1] tag. If they don't have the correct answer then we all are in trouble. – Kevin Jan 21 '12 at 22:08
  • @Kevin its an open source system, everyone can work with the code and product. some widely used parts of the system are not even developed by Composite itself but is contribution from other developers. So there is no guarantee that people working for Composite always have the correct answers. – Pauli Østerø Apr 02 '12 at 09:12