I have an issue with my Laravel project, where I applied localization package for text, but not working for dates as I understood need to be treated in a different way.
I all the project text is correctly translate according to the $locale, but dates as still in English.
I have following settings:
config/app.php
'locale' => 'en',
'fallback_locale' => 'en',
HomeController#home
setlocale(LC_TIME, 'it_IT.utf8');
echo strftime("%H:%M %A, %d %B");
Even with the above code I still read 16:59 Friday, 25 September instead of 16:59 Venerdì, 25 Settembre.
If I run locale -a in Terminal I see a lot of language as well as it_IT.
What am I missing to make the dates following my app()->getLocale()?
many thanks!
the original request was to understand how to apply the above localization by default to all pages of the project showing values like:
{{ $due_date }}
into the locale language.
Related
I am using the webshims library to support older browsers better with more modern features. While the date picker works great with the mouse I seem to be having problems using it from the keyboard. The easiest way to see this is visit the demo page. I am using Firefox since it doesn't have date support.
Without making any modifications try to type in a date. I can enter numbers but I cannot enter a "/". If you enable the placeholder it even suggests the slash. I tried leaving out the separator or using "-" (which it lets me type) but when the form submits I get no value.
How are you supposed to enter a date via the keyboard?
For bonus points is it possible to allow the date picker to not enforce a format? I have backend code that can parse a wide variety of date formats. So they can use the date picker if they wish but if they type something in then whatever they type in is sent onto the server without modification.
Try this.This works for '/' format..
$.webshims.formcfg = {
en: {
dFormat: '/',
dateSigns: '/',
patterns: {
d: "mm/dd/yy"
}
}
};
webshims.activeLang('en');
It appears that there is an issue with the locale settings. From what I can tell, there is a form config attribute called dateSigns that gets set in the locale settings.
The solution for me was to go to file shims/combos/5.js and look for a chunk of code having dateSigns in it. I found the relevant one for US English around line 1750, which looks like this:
if(!formcfg['en-US']){
formcfg['en-US'] = $.extend(true, {}, formcfg.en, {
date: {firstDay: 0},
patterns: {d: "mm/dd/yy"},
dateSigns: '-',
dFormat: "/",
meridian: ['AM', 'PM']
});
}
I updated the dateSigns line to
dateSigns: '/',
It is a horrible hack, and there must be a way to set this as a configuration, or at least get the real locale settings to handle this. But I didn't manage to in the limited time I have available. But maybe this will help you. It works for me.
I'm trying to use trans_choice() to simply format a string to either "comment" or "comments" depending on the number of them. It should be fairly straightforward, like this.
In my view:
{{ trans_choice('posts.num comments', $post->comments->count()) }}
In the posts localisation file:
return [
'num comments' => 'comment|comments',
];
However, every single one returns just "comment". And if I go into tinker:
>>> trans_choice('posts.num comments', 1);
=> "comment"
>>> trans_choice('posts.num comments', 2);
=> "comment"
>>> trans_choice('posts.num comments', 4);
=> "comment"
I'm sure I'm missing something obvious but it looks to me as if I've followed the documentation perfectly.
Edit: The problem seems to lie somewhere in Symfony\Component\Translation\MessageSelector, but I haven't yet figured the cause out.
Finally found the answer. Apparently, if the locale isn't available in Symfony's PluralizationRules class, the translator defaults to the first pick - that is, always index zero. By changing the locale name (I didn't even realise it was misspelled...), I got it working.
I know this post is old, but I ran into this issue, so hoping my solution helps someone if Joel's solution doesn't work.
I'm working with Laravel 7.x, and am using localization on a project for differences between US an CA English, (i.e. Center vs. Centre).
I have my localization folders set up with en being the default folder and en_ca as the Canadian English folder, where en is also the fallback language.
When using trans_choice() I found I had to specifically set the the counts in my translation strings, otherwise the translation engine would just spit back the singular when viewing pages in the non-default locale.
Once the changes were made, trans_choice() worked, no matter what locale was set.
For example, wherever I had:
'general.posts' => 'Posts|Posts',
I changed it to:
'general.posts' => '{1} Post|[2,*] Posts',
After that everything worked.
If you're brazilian that's probably your answer!
I just had the same problem and found out it was because of my locale option (and lang folder).
Instead of 'br' we must use 'xbr' in order to Symphony find it in PluralizationRules (vendor/symphony/translation/PluralizationRules).
In that file there's an array with all languages available, so may check it out.
P.S. I'm using Laravel 5.3
i have multilanguage store. default language is english. there are few products have decimal price.
when i switch languge to spanish the comma appears instead dot in decimal price.
for example: price: 1.35$ in english when i switch language to spanish the price will look like Price: 1,35$
i really wanna remove this , need . how to do that.?
You could try to change the local settings. So go to your magento directory and open the file lib/Zend/Locale/Data/en.xml (replace en.xml by the language file for which you would like to perform your changes).
Search for
<numbers>
<symbols>
<decimal>.</decimal>
<group>,</group>
Clear the cache, also for safer side please try to do this first on your test installation to avoid issues.
You can change your locale setting
here is example for English. For that you have to do Minor changes in your Language File. >Following is the Directory Structure of File.
=> root/lib/Zend/Locale/Data/en.xml (For English Language)
=> around line 2611 you can see following code.
> <currencyFormat>
> <pattern>¤#,##0.00;(¤#,##0.00)</pattern>
> </currencyFormat>
=> Now Change above code with Following code.
> <currencyFormat>
> <pattern>#,##0.00 ¤;(#,##0.00 ¤)</pattern>
> </currencyFormat>
you can set it to for Dutch.
To fix the comma form 1.000 to 1,000
add to the past post the following :
go to: => root/lib/Zend/Locale/Data/XX.xml (XX.xml For your Language)
for example : => root/lib/Zend/Locale/Data/en.xml (For English Language)
around line 2286 you can see following code :
<numbers>
<defaultNumberingSystem> xxx your Language xxx </defaultNumberingSystem>
<symbols>
<decimal>,</decimal>
<group>.</group>
to :
<numbers>
<defaultNumberingSystem> xxx your Language xxx </defaultNumberingSystem>
<symbols>
<decimal>.</decimal>
<group>,</group>
this wil change the comma form 1.000 to 1,000
thanks & regards
Bahattab
I need to change Magento's default decimal format. I mean, when I save '1' to a decimal field, it becomes '10000.0000' with this '.0000' in the end.
I need to change it to another format, which uses ',' instead of '.' to separate decimal (and currency) numbers.
This is the Brazilian standard and it's not being used even after changing the store language. This change should be reflected mainly in the admin side.
Thanks a lot!
==Edited==
I haven't solved the problem yet. I'm using PT-BR (Brazilian Portuguese) as default language and it still using the wrong decimal character.
It seems Magento have some not-localized price formatting (I mean, hard-coded) in a few points of code. For example: magento\js\prototype\validation.js at line 426 have:
|| (!isNaN(parseNumber(v)) && /^\s*-?\d*(\,\d*)?\s*$/.test(v));
but instead it needs to be
|| (!isNaN(parseNumber(v)) && /^\s*-?\d*(\,\d*)?\s*$/.test(v));
to fit into PT-BR format (or other locales to).
Am I right? Does anybody could fix this issue?
if you want to check in admin area for this change
you go to in admin left bottom drop down
and select
Português (Portugal) / português (Portugal)
it will show you currency as you want. Also if you doesn't install you package go to
http://www.magentocommerce.com/translations/list/19
download your package and add it to your
locale folder and select from configuration for front end also
hope this will sure help you.
I've applied the following change to the file magento\js\prototype\validation.js (line 426):
|| (!isNaN(parseNumber(v)) && /^\s*-?\d*(\,\d*)?\s*$/.test(v));
and also, changed the file lib/Varien/Data/Form/Element/Abstract.php by adding the first if statement:
public function getEscapedValue($index=null)
{
$value = $this->getValue($index);
if(is_numeric($value)){
$value= number_format($value, 3, ",", ".");
}
...
this changes have solved the problem so far. Do you see any side-effect?
Comments are welcome! Thanks!
Newer versions of Magento are based on Zend Framework currency locale format so the best way to do this is to change the language.xml from the Zend directory, more information is on this great article.
Quite simply: I'm using Smarty and the |capitalize modifier. It works fine, but when I pass any word with l in it, it capitalizes it, even if it's not at the beginning of the word.
What why?
EDIT: Same happens with p.
Test:
{"abcdefghijklmnopqrstuvwxyz"|capitalize}
{"aaal aala alaa laaa"|capitalize}
{"aaap aapa apaa paaa"|capitalize}
Output:
AbcdefghijkLmnoPqrstuvwxyz
AaaL AaLa ALaa Laaa
AaaP AaPa APaa Paaa
You could also use PHP's ucfirst function
{"aaal aala alaa laaa"|#ucfirst}
This will result in
Aaal aala alaa laaa
Smarty primarily relies on ucfirst() which is affected by the current locale set in PHP. I have been unable to find information on exactly how this affects the capitalization functions (ucfirst, strtolower, strtoupper, etc), but you can try setting your locale to en_US.UTF-8 (what works on my server) and see how that affects the output.
view locale:
var_dump(setlocale(LC_CTYPE, null));
change locale:
setlocale(LC_CTYPE, "en_US.UTF-8");
Update
Some research leads to a few archives where a customer modifier is written to either pick the local for the modifier or a custom function to set the locale from the template file.
Source 1
Source 2
I haven't been able to reproduce this. Could it be the font you are using (some tail the l)? Do you have code examples?
With Smarty v2
{assign value="let go" var="go"}
{$go|capitalize}
<br/>
{assign value="allow me" var="me"}
{$me|capitalize}
Outputs
Let Go
<br/>
Allow me