PSR-2 VS Codeigniter Framework Style guidelines - codeigniter

There are contradictions between PSR-2 and Codeigniter Style Guidelines:
Allman style indenting in CI which is discouraged in PSR-2
elseifs on new line in allman
private methods in classes prefixed with underscore in CI and NOT in PSR-2.
TRUE, FALSE, NULL caps in Codeigniter and lowercase in PSR-2.
Tab in Codeigniter VS 4 spaces for indenting in PSR
Some more occurences like this but you get the point.
I am thinking of favoring PSR-2 over Codeigniter Style guidelines.
Thoughts?

Related

Drupal 8 stripping style attributes from table tags

I'm using Full HTML filter, with CKEditor. The following filters are enabled:
Align images
Caption images
Track images uploaded via a Text Editor
Collapsible text blocks
Note that Limit allowed HTML tags and correct faulty HTML is NOT enabled.
when I add a style attribute to a table element in Ckeditor using the Source view, specifically "width=75%", it is stripped when the page is rendered. When I edit the page again and go to Source view, the style tag is there.
What is stripping it on render?
I believe inline styles are removed by default for security reasons. But, there has been a lot of discussion about this issue on Drupal.org over the past few years. If you're looking for a workaround and accept the risk, here are two approaches I have found:
How to fix: CKEditor is removing style attributes. Drupal 8.
Refactor Xss::attributes() to allow filtering of style attribute values
Fair warning: I have not personally implemented either of these.
Inline style is stripped by default with Basic HTML formatter. Unless you have a specific reason why you don't want to turn on Limit allowed HTML tags I highly recommend that you do because it gives you a lot of control over what tags you and others can use in the wysiwyg. In addition, it allows you to add a "Styles" button with pre-configured styles so you don't have to insert inline CSS code repetitively.

AEM How to prevent localization happening otb?

I have a scenario wherein i18n becomes overhead to content authors. The authors want dialog labels to be in English only for all locales. But certain headings/labels on dialog gets localized as they are available in otb dictionaries. Example label 'Advanced' from page properties dialog gets translated for non-english sites.
Is there a way I can prevent internalization happening?
If you refer to AEM's documentation for i18n, you can see its driven by the locale/language set in slingRequest. you can override this by explicitly fixing the i18n but if you do that none of your translations will work -
Locale pageLang = new Locale("en");
ResourceBundle resourceBundle = slingRequest.getResourceBundle(pageLang);
I18n i18n = new I18n(resourceBundle);
An other alternative (a little extra effort) in you need to do this only for dialog boxes is -
Create your own dictionary for translations, refer here
Use unique name-spacing for your keys eg - myapp.mycomponent_abc.label
Use above keys in your component dialog to ensure that your version of translation is picked. If for all languages you want english only dialogs, all your have to do is duplicate your english dictionary and change the language key in it to relevant language while keeping translations still in english.

Translate joomla K2 template sentence

I have a joomla website with 5 subtemplate K2.
The website is multilingual and I want to translate some sentences in subtemplate.
Where I can put this translation ?
I think it's in de-DE.com_k2.ini but in the next K2's update, sentence will be erase ?
Thank you for your time
You can either edit the appropriate files in
/language/overrides
or use the Language override feature in your administrator backend (Administrator-Extensions-Language management-Overrides). There you can search for text, find the language constants, and provide your custom localisations, which will persist across components' and Joomla! updates.

New Line in localization string in C#

I have a site developed in C#.net and VS2010. It is is localized and works well overall. However, some of the localization strings don't look the best.
For example, I have a message at the top of the login page
Currently it appears like this:
Your session has expired. Please login to
continue.
I would like it to appear like this:
Your session has expired.
Please login to continue.
I can't change the size of the containing div because the width could be different for each language.
I am looking for a way to put layout capabilities in the localization file. The simplest approach (on the surface) is to put new line characters in the string. However, \n, \r\n, and <br/> all appear in the string because it is rendered with " around the string.
Is there another approach that will work? Is this a bad idea? How else can we compensate for length differences accross the many languages?
The best approach in this case is to use HTML formatting in your string (both in English and in your translation) and where necessary adjust the translation.
There is no reason why you could not include <br /> in your string and have it rendered as intended. I don't know if you are using WebForms or ASP.NET MVC, but in the case of MVC you can avoid the default behaviour (automatic HTML encoding of your string) by using the Html.Raw helper, for example instead of this:
<div class='whatever'>#Resources.MyString</div>
Do this:
<div class='whatever'>#Html.Raw(Resources.MyString)</div>

Symfony2 Rookie: Internationalization with special routes and css

i am currently in the process of learning Symfony2. and i love its cleaniness and professionality
i am wondering what is the easiest way for me to implement this, and make my code easily extendable.
my main site should be english www.mysite.com , www.mysite.com/aboutus, www.mysite.com/contact
the second site should be arabic, and links reachable under www.mysite.com/ar, www.mysite.com/ar/aboutus, www.mysite.com/ar/contact
when i click on chosing arabic language, i should be able to chose a different twig template, optimized for RTL (right to left)....and special CSS....etc
i know i can do this with routing and twig....but i cannot (yet) pinpoint the shortest path :oops:
i would appreciate any help :)
For i18n routing, checkout JMS's awesome JMSI18nRoutingBundle. As for per-language twig templates, there are multiple ways to skin this cat, however the most straightforward would be to create a per-language template file and define that when rendering. For example:
public function indexAction($name)
{
return $this->render("AcmeHelloBundle:Hello:index.html.{$this->get('session')->getLocale()}.twig", array('name' => $name));
}
Make sure you create both index.html.en.twig and index.html.ar.twig templates.

Resources