Although the official documentation of the country field in AlpacaJS states that "The names of the countries are read from the I18N bundle for the current locale," I can't make the translation work.
I have tried to set the locale using the following two ways described on their internalization documentation without success:
$.alpaca.setDefaultLocale('pt_BR');
"view": {"locale": 'pt_BR'}
In the first case, I set it up while loading all "webapp" configurations while the second is part of the form configuration and should be set when alpaca builds the form. In both cases, all the other functionalities work, except the translation of the country names.
What am I missing?
Sadly they didn't do it, they put only common validation and date messages in the locale bundles and they didn't translate the country field values!
You did it well setting the view locale though, your code works normally except in locale files you will not find any translation for country names so alpaca do like a fallback to base locale file... so unfortunately you should do it yourself by extending the country field values in the view like the following:
"messages": {
"es_ES": {
"countries": {
"tun": "TunÃsia"
...
}
}
}
And you should complete all the list or you will get a country field with only the values you put in the previous view code
here's a fiddle for this.
Related
I have overridden the APPrintChecks data view to sort by Vendor Code. But since the client's VendorCodes are all numeric, they would like to see the checks sorted so that, for example, VendorCode '357' is printed before VendorCode '10021'.
Any ideas on how I can accomplish that?
public class APPrintChecks_Extension : PXGraphExtension<APPrintChecks>
{
//change sort from Vendor Name to Vendor Code
[PXFilterable]
public PXFilteredProcessingJoin<APPayment, PrintChecksFilter,
InnerJoin<Vendor, On<Vendor.bAccountID, Equal<APPayment.vendorID>>>,
Where<boolTrue, Equal<boolTrue>>,
OrderBy<Asc<Vendor.acctCD, Asc<APPayment.refNbr>>>> APPaymentList;
}
As per suggestion in the comments, I would first check if there is another numeric/date field you can sort on such as BAccountId or CreatedDate. If this will not do, you will need to find a more creative way to fix it such as:
Changing Vendor Code Numbering Sequence to include leading zeros,
example: 0000357, 001021
Adding a custom field (which is stored in the database) and setting this custom field in the graph to include the leading zeros. Example
add field UsrVendorCode of type string where you add the leading
zeros in an event (of the Vendor Graph) such as RowPersisting.
Adding a calculated database field to add leading zeros and adding this as a custom field (extension of Vendor) in Acumatica (not sure
whether this is fully supported by Acumatica since it requires
modifications in DB)
I am confused about wiring up my own datasource to the Kendo Scheduler. I looked at their API and I'm still confused. For instance, I see it says the start and the end are required, but are they the names of the fields in my dataset? They can't be mapped to another name?
My dataset has some other details as well as a date in the format, "2016-10-20T00:00:00." Is this going to work?
Can someone tell me if the actual field names from the DB/JSON are literally the same as in Telerik's docs? For instance, my date field isn't called "Start" and End. It's something else, and I don't even have an end, and I don't have starttimezone and endtimezone, are these all needed?
Another question I have is: I'm not limited to just the fields from their documentation am I? I have a datasource that has other things, for instance, we don't have "title," we have something else. And riding off that question, I'm hoping that when I call the pop up when the user double clicks on a time/day or event, that I can customize what fields I want to appear.
The other question is: What is the "from" attribute/property for? For instance
end: { type: "date", from: "End" },
Thanks
My two cents on this:
I think the options "Title", "Start" and "End" are the ones that are always needed on the dataSource. "startTimezone" and "endTimezone" are not always needed.
I also think that the "from" attribute/property is a reference to from where you are getting that data. I mean, which field from the database guards a specific information.
You can also have your own custom fields to the model, as long as they came from a valid field from the database and as long as they have an correspondent and valid datatype value.
At last but not the least, you can also customize what fields you can make appear once you do double-click and the pop-up window shows up. For that, you must use your own template for a custom pop-up editor.
Hope this gives you some insight.
Thanks for the help. I figured out the core issue with the error. It was a matter of me tweaking my schema model.
I'm new to Dojo and i18n for that matter. I am looking to convert a couple of works to different languages in my app. I've read through a few articles and to be honest, I feel like a LOT of information is thrown at me to digest, and I'm struggling with it. Would someone be able to provide me with the simplest way I can possibly do this? Let's say I want to change the word 'Hello'. In my head it would be something like:
Dojo library ready for use
I define String 'hello' in my javascript file. It has the placeholder text of "hello"
I specify in my HTML that I want my page to be
"string specified here to display hello in a different language"
So that's as much as I can assimilate from my limited knowledge. How do I essentially get that sort of setup to work? I assume I need to require i18n on my page, but exactly how I execute this is still to be determined.
Any help would be super. Please bear in mind that I have a limited knowledge with your answer if at all possible, thanks!
The nls folder is normally used to store your translation strings and is usually a subdirectory next to the widget using it.
ie. If your widget is stored in myWidget.js within a folder called app, then your translation strings for myWidget.js are stored in a file with the same name (myWidget.js) in the directory app/nls.
This is just convention but is probably worth following as it makes your directory structure logical.
Here is an example of the myWidget.js widget:
define([
"dojo/_base/declare",
"dijit/_WidgetBase",
"dijit/_TemplatedMixin",
"dojo/i18n!./nls/myWidget"
], function(
declare, _widget, _templated, strings, domAttr
){
"use strict";
var construct = declare([_widget, _templated], {
"i18n": strings,
"templateString": "<div>${i18n.hello}</div>"
});
return construct;
});
This is a very simple widget that creates a <div> (see templateString property) on the screen. The <div> should contain the text loaded from the translation file and assigned to the hello property.
The widget will need nls directory creating in the same directory as myWidget.js. In the nls directory you create another javascript file called myWidget.js (ie. same name as the parent). This file is you root translation file and looks like this:
define({
root: ({
"hello": "Hello"
})
});
Here you have assigned the string, "Hello" to the property hello. This is not very useful as no translations have been supplied. If you wanted to have a Norwegian translation then you would modify it like this:
define({
root: ({
"hello": "Hello"
}) ,
"no": true
});
Here you are saying that as well as the root translation strings you also have a Norwegian translation. You will then need to create your Norwegian translation file and place it in a subdirectory of nls called no. So you create another file called myWidget.js and place it in nls/no:
define({
"hello": "Hei"
});
The format for the translation file is slightly different to the root file. The default strings are used, unless a translation is available for the given string in the current browser language (ie. you do not need to translate every string, just the ones you want translating).
See the Dojo tutorial for internationalization for more help on this subject.
See sample project for the above code on Bitbucket
Loading translation-strings outside of widget:
The above examples show how to load translation text for a widget following the normal conventions. You can load any set of strings you want in any widget or any require statement. The dojo/i18n class is able to load any set of strings you specify.
eg:
require([
"dojo/i18n!<PATH TO TRANSLATION ROOT FILE YOU WANT TO LOAD>"
], function(string) {
// translation-string are stored in the 'strings' variable for the
// current browser language
});
We are beginning to allow multi-national registrations and have the requirement to split the phone number entry in the OnePage checkout billing.
We want to add Country Code and split the rest into Area Code Number and Extension fields. Then we will need to concatenate them into one before storing them.
How would I accomplish that?
Could you not just use a hidden field and javascript? So add 2 fields, then use onchange="phonecat()" on each to trigger a function that concatenates then values and assigns them to the pre-existing telephone field, which you have changed to be type="hidden".
Something like the following in JQuery:
function phonecat() {
$(function(){
newphone = jQuery("#initialphone").val() + jQuery("#latterphone").val();
jQuery("#billing\\:telephone").val(newphone);
}(this.jQuery));
}
I've not tested this exact solution, but I've used something similar in the cart. Only the (now hidden) proper field will be passed and used.
File is .../persistent/checkout/onepage/billing/phtml in 1.6 (without persistent/ earlier). And you'll need to define the function somewhere too.
Can Magento view/manage our customers by their business name in addition to their contact names to find them easily? It is being used for B2B, so when emails go out they are pulling the customer’s name, instead of the company name which is more appropriate.
Is this a global setting?
thanks in advance.
Magento stores business name on the customer's address by default, so it's a little harder to get to.
There's no reason you cannot add another customer field to put the company name on the customer record itself. That way you'll have no problem accessing it, and can change other screens in the system to reflect it.
If you don't want to go to those lengths, you could always implement a method that pulls the company name from the default address, and save it into the session by default, for easier retrieval.
EDIT: Better idea.
Looking through the sales email templates, there are two methods that are used to grab a customer's name:
$order->getCustomerName();
$order->getBillingAddress()->getName();
I don't see any separate references to the company name, so you should be able to substitute these two methods for your own and get the desired outcome. You'll need to create your own module and override the models for customer/address and sales/order (others have covered this in depth elsewhere). Then create methods that look something like this:
public function getCustomerName() {
if($this->getBillingAddress()->getCompany()) {
return $this->getBillingAddress()->getCompany();
}
return parent::getCustomerName();
}
That's the example for sales order, modify accordingly for customer. Now your company names will be used whenever available, and when they aren't the fallback will be to the original implementation (customer name).
Hope that helps!
Thanks,
Joe
You are correct about the universal application. If you did want just the emails, the concern is whether you have access to your custom function where you need it. If there's no object handy, I'm not positive that you will be able to call just any method that you need to.
An approach that would work in this case would be to override the two objects mentioned below, but to instead add a getCompanyName method to them. That way, you'll have the right objects to call, and you can edit the emails specifically to taste.