Magento: Decimal Price in spanish language display Dot instead comma - magento

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

Related

How to show currency symbol (¥) in numeric?

I was able to get default USD $,using
cellProperties.type = "numeric";
cellProperties.format = "$0,0.00";
How to show CNY ¥ in numeric?
I tried,
cellProperties.type = "numeric";
cellProperties.format = "¥0,0.00"
It shows only number with thousand comma, no any currency symbol, no error. Any help would be appreciated.
Handsontable uses the Numeral.js library to handle its number formatting. As it's written in the docs, the currency symbol (as well as other display options) depend on the "locale" of the cell, configurable via the language: option. To get it running for CHN, include the corresponding translation file and then set the language to 'chn':
<script src="https://docs.handsontable.com/0.24.3/bower_components/numeraljs/languages/chs.js"></script>
Here's a sample JSFiddle snippet to demonstrate your use-case.

Why does Laravel's trans_choice() always show the singular case?

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

Change Magento decimal field format

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.

Removing .00 in configurable attribute price in Magento

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.

Algorithms or Patterns for reading text

My company has a client that tracks prices for products from different companies at different locations. This information goes into a database.
These companies email the prices to our client each day, and of course the emails are all formatted differently. It is impossible to have any of the companies change their format - they will not do it.
Some look sort of like this:
This is example text that could be many lines long...
Location 1
Product 1 Product 2 Product 3
$20.99 $21.99 $33.79
Location 2
Product 1 Product 2 Product 3
$24.99 $22.88 $35.59
Others look sort of like this:
PRODUCT       PRICE   + / -
------------  -------- -------
Location 1
1             2007.30 +048.20
2             2022.50 +048.20
Maybe some multiline text here about a holiday or something...
Location 2
1             2017.30 +048.20
2             2032.50 +048.20
Currently we have individual parsers written for each company's email format. But these formats change slightly pretty frequently. We can't count on the prices being on the same row or column each time.
It's trivial for us to look at the emails and determine which price goes with which product at which location. But not so much for our code. So I'm trying to find a more flexible solution and would like your suggestions about what approaches to take. I'm open to anything from regex to neural networks - I'll learn what I need to to make this work, I just don't know what I need to learn. Is this a lex/parsing problem? More similar to OCR?
The code doesn't have to figure out the formats all on its own. The emails fall into a few main 'styles' like the ones above. We really need the code to just be flexible enough that a new product line or whitespace or something doesn't make the file unparsable.
Thanks for any suggestions about where to start.
I think this problem would be suitable for proper parser generator. Regular expressions are too difficult to test and debug if they go wrong. However, I would go for a parser generator that is simple to use as if it was part of a language.
For these type of tasks I would go with pyparsing as its got the power of a full lr parser but without a difficult grammer to define and very good helper functions. The code is easy to read too.
from pyparsing import *
aaa =""" This is example text that could be many lines long...
another line
Location 1
Product 1 Product 2 Product 3
$20.99 $21.99 $33.79
stuff in here you want to ignore
Location 2
Product 1 Product 2 Product 3
$24.99 $22.88 $35.59 """
result = SkipTo("Location").suppress() \
# in place of "location" could be any type of match like a re.
+ OneOrMore(Word(alphas) + Word(nums)) \
+ OneOrMore(Word(nums+"$.")) \
all_results = OneOrMore(Group(result))
parsed = all_results.parseString(aaa)
for block in parsed:
print block
This returns a list of lists.
['Location', '1', 'Product', '1', 'Product', '2', 'Product', '3', '$20.99', '$21.99', '$33.79']
['Location', '2', 'Product', '1', 'Product', '2', 'Product', '3', '$24.99', '$22.88', '$35.59']
You can group things as you want but for simplicity I have just returned lists. Whitespace is ignored by default which makes things a lot simpler.
I do not know if there are equivalents in other languages.
You have given two pattern samples for text files.
I think these can be handled with scripting.
Something like: AWK, sed, grep with bash scripting.
One pattern in the first sample,
Section starts with keyword Location [Number]
second line of section has columns describing product names
third line of section has columns with prices for the products
There can be variable number of products per section.
There can be variable number of sections per file.
Products and prices are always on their designated lines of a section.
Whitespace separation identifies the (product,price) column-association.
Number of products in a section matches the number of prices in that section.
The collected data would probably be assimilated in a database.
The one thing I know I would use here is regular expressions. Three or four expressions could drive the parse logic for each e-mail format.
Trying to write the parse engine more generally than that would, I think, be skirting the edge of overprogramming it.

Resources