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
Related
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.
(It's been a while since I've been here.)
I've been using the first version of PHRets v1 for years, and understood it well enough to get by, but now I'm trying to understand the advantages of v2.6.2. I've got it all installed and the basics are working fine. My issues are pretty much with comprehending fine points of query syntax that goes into the rets=>Search() statement. (I'm much more familiar with SQL statements). Specifically, I'd like to have a query return a list of properties, EXCLUDING those which already have the status of "Sold".
Here's where I am stuck: If I start with this
`$results = $rets->Search('Property', 'A','*',['Select' => 'LIST_8,LIST_105,LIST_15,LIST_19,listing_office_shortid']);`
That works well enough. BUT I'd like to fit in a filter like:
"LIST_15 != Sold", or "NOT LIST_15=Sold"...something like that. I don't get how to fit/type that into a PHRets Search().
I like PHRets but it is so hard to find well-organized/complete documentation about specific things like this. Thanks in advance.
As in my comment above I've figured out that the filter goes in the third argument position ('*', as in the original question). The tricky thing was having to find a specific "sold" code for each class of properties and placing it in that position like so: '(LIST_15=~B4ZIT1Y75TZ)', (notice the =~ combination of characters that means "does not equal" in this context). I've found the code strings for each of the property types (not clear WHY they would need to be unique for each type of property: "Sold" is Sold for any type, after all) but the correct code for a single-family residential property (type 'A' ...at least for the MLS in which I have to search is:
$results = $rets->Search('Property', 'A','(LIST_15=~B4ZIT1Y75TZ)',['Select' => 'LIST_8,LIST_105,LIST_15,LIST_19,listing_office_shortid']);
(again, the code to go with LIST_15 will be different for the different types of properties.) I think there is a better answer that involves more naturalistic language, but this works and I guess I will have to be satisfied with it for now. I hope this is of some use to anyone else struggling with this stuff.
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 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.
I'm currently building a code generator, which aims to generate boiler plate for me once I write the templates and/or translations, in whatever language I have to work with.
I have a problem with a regex in Ruby. The regex aims to select whatever is between {{{ and }}}, so I can generate functions according to my needs.
My regex is currently :
/\{\{\{(([a-zA-Z]|\s)+)\}\}\}/m
My test data set is:
{{{Demande aaa}}} => {{{tagadatsouintsouin tutu}}}
The results are:
[["Demande aaa", "a"], ["tagadatsouintsouin tutu", "u"]]
Each time the regex picks the last character twice. That's not exactly what I want, I need something more like this:
/\{\{\{((\w|\W)+)\}\}\}/m
But this has a flaw too, the results are:
[["Demande aaa}}} => {{{tagadatsouintsouin tutu", "u"]]
Whereas, I wish to get:
[["Demande aaa"],["tagadatsouintsouin tutu"]]
How do I correct these regexes? I could use two sets of delimiters, but it won't teach me anything.
Edit :
All your regex run against my data sample, so you all got a point.
Regex may be overkill, and probably are overkill for my purpose. So i have two questions.
First, do the regex keep the same exact indentation ? This should be able to handle whole functions.
Second, is there something fitter for that task ?
Detailled explanation of the purpose of this tool. I'm bored to write boiler plate code in php - symfony. So i wish to generate this according to templates.
My intent is to build some views, some controllers, and even parts of model this way.
Pratical example : In my model, i wish to generate some functions according to the type of an object's attribute. For examples, i have functions displaying correctly money. So i need to build the corect function, according to my attribute, and then put in , inside m output file.
So there is some translations which themselves need translations.
So a fictive example :
{{{euro}}} => {{{ function getMyAttributeEuro()
{
return formating($this->get[[MyAttribute]]);
} }}}
In order to stock my translations, should i use regex, like
I wish to build something a bit clever, so it can build most of the basic code with no bug. So i can work on interesting code.
You have one set of capturing parentheses too many.
/\{\{\{([a-zA-Z\s]+)\}\}\}/
Also, you don't need the /m modifier because there is no dot (.) in your regex whose behaviour would be affected by it.
I'm partial to:
data = '{{{Demande aaa}}} => {{{tagadatsouintsouin tutu}}}'
data.scan(/\{{3}(.+?)}{3}/).flatten.map{ |r| r.squeeze(' ') }
=> ["Demande aaa", "tagadatsouintsouin tutu"]
or:
data.scan(/\{{3}(.+?)}{3}/).flatten.map{ |r| [ r.squeeze(' ') ] }
=> [["Demande aaa"], ["tagadatsouintsouin tutu"]]
or:
data.scan(/\{{3}(.+?)}{3}/).map{ |r| [ r[0].squeeze(' ') ] }
=> [["Demande aaa"], ["tagadatsouintsouin tutu"]]
if you need the sub-arrays.
I'm not big on trying to everything possible inside the regex. I prefer to keep it short and sweet, then polish the output once I've found what I was looking for. It's a maintenance issue, because regex make my head hurt, and I stopped thinking of them as a macho thing years ago. Regex are a very useful tool, but too often they are seen as the answer to every problem, which they're not.
Some people, when confronted with a problem, think “I know,
I'll use regular expressions.” Now they have two problems.
-- Jamie Zawinski
You want non capturing groups (?:...), but here is another way.
/\{\{\{(.*?)\}\}\}/m
Just a shot
/\{\{\{([\w\W]+?)\}\}\}/
Added non-greedyness to your regex
Here this seems to work