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.
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 am converting a character variable to a numeric variable. I am using a bestw.d format. I also tried just best. as the format in the input statement and this worked fine. I cant find any mention of just using best. instead of bestw. in SAS help, though I know from SAS help that the d can be omitted. I have been playing around with using just the best.and I am wondering if there is a default w assigned when just using best..
All formats have a default w. It is not generally good practice to use best. (or <format>.) in most cases, as you should know and plan for the specific width needed, but it always exists.
Also, informat and format have different defaults in many cases where there are identically named informat and format.
In the case of bestw., the default length is 12. See this documentation page for details.
I always find it's worth using a worked example, this shows the different outcomes when using lengths on the BEST. format:
data _NULL_;
a=1031564321300.302;
put '==================================';
put 'Different "BEST" formats';
put '==================================';
put 'BEST8. - ' a best8.;
put 'BEST12. - ' a best12.;
put 'BEST13. - ' a best13.;
put '==================================';
put 'BEST. - ' a best.;
put '==================================';
run;
You can run this in your environment and check the outcome. On my machine it looks like this:
==================================
Different "BEST" formats
==================================
BEST8. - 1.032E12
BEST12. - 1.0315643E12
BEST13. - 1031564321300
==================================
BEST. - 1.0315643E12
==================================
i.e. It looks like BEST12. is the matching format when no width is specified.
The currency I'm using in the Magento site I'm creating is Japanese Yen which does not have decimals in their currency. I've managed to remove it from my product page and cart.
By modifying app/code/local/Mage/Directory/Model/Currency.php inside format function like so:
$locale = Mage::app()->getLocale()->getLocaleCode();
if($locale != 'ja_JP') {
return $this->formatPrecision($price, 2, $options, $includeContainer, $addBrackets);
} else {
return $this->formatPrecision($price, 0, $options, $includeContainer, $addBrackets);
}
However, in the dropdown attribute I created, the decimal still shows. Like so:
White - ￥3000.00
Blue - ￥5000.00
In my dropdown attribute, how can I drop .00 at the end of the price? Also, is it possible to drop decimal for the admin without altering the database?
I've tried searching but sadly, Magento does not have a direct feature that would handle this. Or at least I haven't come across said feature.
You can add this piece of code on beginning of formatTxt method in the same class you was editing:
if(Mage::app()->getLocale()->getLocaleCode() == 'ja_JP') {
$options['precision'] = 0;
}
This will change the precision for prices in almost every place inside Magento (like Catalog, Checkout, even Administration).
Check code of free ET_CurrencyManager extension to find a solution. You need to modify more that one funstion in Mage_Directory_Model_Currency. Also you need to modify precision for JS scripts too in Mage_Core_Model_Locale::getJsPriceFormat.
Or just use this extension to avoid core files modifications.
In fact the Zend local format for JA (Japnese) is wrong, see file:-
httpdocs/lib/Zend/Locale/Data/ja.xml
Line: 2953 (or just search for "0.00")
Update to the following:-
<currencyFormats>
<currencyFormatLength>
<currencyFormat>
<pattern>¤#,##0</pattern>
</currencyFormat>
</currencyFormatLength>
</currencyFormats>
This will completely change the YEN display price to have zero decimals within the JA Locale.
A couple of words of warning...
The admin area if viewed in any locale other than ja_JP will allow a
decimal price to be entered, entering a YEN price with a decimal
position of anything other tha ".00" will result in a checkout price
mismatch error.
It appears that Magento will always send prices to
PayPal with two decimal positions and this will cause price mismatch
errors when applying coupon or Sale discounts (Mage 1.6) - I'm
currently working through this issues on this and testing against
1.9 Version.
Okay, so I managed to remove .00 by modifying configurable.js and product.js. It's not a direct solution but a workaround.
For each file, I split the price string removing any decimal points(.) and numbers succeeding it by using the split function of javascript. So I added something like so:
var a = price.split(.);
return a[0];
Using that, all the decimals have been dropped from my prices. Thanks for all your time and help.
How does the Grails tag fieldValue perform its formatting?
I have an domain class with an Double attribute.
class Thing {
Double numericValue
}
In GSP, the fieldValue is used (as created by grails generate-all) for rendering:
${fieldValue(bean:thing, field:"numericValue")}
Unfortunately digits after 3 decimal places are not displayed (ie, 0.123456 is displayed as 0.123). How do I control fieldValue's formatting?
Note that I could just use ${thing.numericValue} (which does no formatting) or
<g:formatNumber>, but I'd rather use the fieldValue tag and specify the formatting. I just don't know where to specify fieldValue's formatting.
Use
<g:formatNumber number="${thing.numericValue}" format="\\$###,##0.00" />
instead or use
${g.formatNumber(number:thing.numericValue, format:'\\$###,##0.00'}
Hope this helps.
An alternative to the answers above is using the i8n files. This option is useful since it can be changed for "All" and depending on the locale
if you go to the messages.properties file you can add the following
default.number.format = ###,##0.00
This will change the default format for all numbers.
If you plan on using the g:formatNumber tag i would suggest using it as
<g:formatNumber number="${myNumber}" formatName="myCustom.number.format" />
and adding the code entry to the messages.properties files as:
myCustom.number.format = ###,##0.00
by doing this you will only need to use the code wherever you need a similar number format, and, if needed make the changes in a single place.
It would be in your best interests to read this article from the grails docs.
OFFTOPIC: As a side note you can also change the default date format in the messages.properties file as follows
default.date.format=dd 'de' MMMM 'de' yyyy