I managed to change once these endpoints of WooCommerce --> /my-account/addresses/billing-address/ or /shipping-address/ or /add-address/. The problem is that I changed them to Cyrillic when I need to go back to Latin, and now I can't find those anywhere! Do you know how I can manage to change those, they're not in the advanced settings?
I need to find a way to change those again. In my language, it looks like that: /moyat-profil/adresi/фактуриране, in English: /my-account/addresses/billing-address/ I have to change 'фактуриране' to Latin.
P.S. I clearly remember that once they appeared in the backend of WordPress and I changed them simply from there. However, I'm not able to find them again.
Related
I am using Weglot Translation Plugins in WordPress. Everything working fine except checkout payment section not updating that's why the translation not working for that particular section
Check below the screenshot
https://prnt.sc/1zs8ptj
I'm Edson from weglot developper team.
Regarding your problem there are 2 things:
1- first of all, you should check from the dahboard if your translation is present. If not, one of the first ways is to see if you haven't gone over your word limit.
2- The error you are reporting seems "normal" because the Visual Editor must be used for "static" pages. In your case, you seem to be using the tool to translate an order page containing Ajax calls which notably causes CORS header issues.
I hope this will help you and do not hesitate if you have any questions to contact our support team
Best
I'm having a bit of a major meltdown regarding a translation of a site. It's a wordpress site with a WooCommerce shop. LocoTranslate and Avada is installed.
The issue is, that some individual strings of text are not being translated - even when i've changed the .po file (with PoEdit).
For example, there's a string on the customer cart that says:
"hello USER (not USER? Sign out)"
In PoEdit it looks as such:
Hello %1$s (not %1$s? Sign out)
I'm adding a translation that says:
Hej %1$s (ikke %1$s? Log ud)
It's just not being updated on the site!
Does anyone know what I'm doing wrong??
There are 2 other words that won't be translated either :(
I work a lot with dual language WP sites and find this quite often. In most cases it dues to the textdomain being called before the strings in question are being called. In theory this shouldn't happen but it does. The solution that usually works for me is to add the textdomain a second time in yours functions file and use a hook that runs much later in the site loading process. This invariably fixes it although it a bit of a hack.
If this isn't working and you only need the site in one language you can create a child theme and manually translate the stubborn strings in the page template.
I am building site in Drupal and I need your help. I have an assignment to make one more language translation of the site, and so far so good. However, I have one trouble with one block which isn't going to get translated, even though in the settings I translated it.
Also one strange activity I noticed is that when I try to go to VIEW section of all the other languages, I get dropped to front page (where that block is actually located) but if I press VIEW from my language translation (Swedish) of the block I get to completely new page.
If I go to front page and my language is selected, that block is actually using default language.
Any help what may cause it?
For desire url aliasing you need to install pathauto drupal module. then you can configure alise from below url
admin/config/search/path/patterns
OK, I have found a solution to this problem.
It appears that Drupal 7 by default sets your new language homepage to the default homepage and that's why this block was using default language since it was relying on the front page. Anyway, to fix the issue follow the steps:
Login to adming account, go to Configuration, System, Site Information and in the field Default front page for the language you have chosen navigate to your specific node page. That's it.
This may be an obvious question for those of you more advanced in coding than myself...but I created a website in WordPress but their domain is hosted elsewhere. They changed the A name and it now points to the site, but the font awesome icons are now square boxes. How can I fix this? Is there a simple way?
Many thanks for any help/guidance.
Alison
Super late, but hopefully this saves someone a lot of time. After migrating an existing Wordpress site to a new domain, I too encountered icons missing (both on the front-end and the back-end administration). After a long search and applying different methods, I found the database still listed the original/old domain within the "option" table.
Using phpMyAdmin, select the "option" table. Within "option" you will see the "site" and "home" rows. If the value has the old domains, you will need to change it to match the sites URLs (Located on the Administration dashboard under Settings > WordPress Address (URL) & Site Address (URL). To change the value, click Edit > and update the URL.
Fix the problem in less then 2 mins. Simple replacement of /font-awesome/5.13.0/css/fontawesome.min.css with /font-awesome/5.13.0/css/all.min.css and also font-awesome/5.13.0/js/fontawesome.min.js with /font-awesome/5.13.0/js/all.min.js can fix this issue. https://youtu.be/_GV_pEmLCLU
I know this is 2 years old, but I just ran into a similar problem and the answer given by Owais did not feel right to me (getting CSS from another site).
This happened to me for the exact same reason as it did for OP. I migrated my website to another host and another domain-name. After doing that I ran a rename-script for the DB (thousants of hard-coded URLs were replaced).
However, as it turns out, my theme was also using hard-coded URLs in the CSS files and in some JS files, as they were generated (upload/fusion-scripts and upload/fusion-styles). After replacing the hardcoded URLs in these files (I used visual studio, but you can use any bulk-replace tool) everything worked fine again.
Just another idea to throw in here - after transferring the site to the new server, and running this handy script to replace all references of the old url with the new one, I was still having the same issue with font awesome. The solution was to go to Settings / General and set the Endurance Cache to Off (0). Refreshed the site and all was well.
In my case, I had that problem changing the url using the constants WP_HOME WP_SITEURL at wp-config.php
When I changed through the wp-admin using the RELOCATE flag, worked
As you may know, this is the official doc about it
I had this problem so many times but this time I found the full proof solution for this issue:
Open PhpMyAdmin and then click on wp_options table.
In this, you will see a table with a name(according to your theme name) something like "theme_options_css" edit it and change the URL from old to new.
The problem might occur due to Http to Https migration also. So for that also change Http to Https manually in the same table and the problem will be resolved the moment you save your table.
I have a site entirely in English language about tourism in Italy.
Now when the user clicks on "Paypal express check out" button finds the italian version of the Paypal Page.
I would like to force paypal to be in English language too, because if a customer speaking english language comes in Italy, he would like to have also paypal in the same language of the site and not based on his IP address, Browser Location, or anything else.
So, my question is: how can i be sure that all visitors see Paypal in the same language (English) of the rest of the site?
I have Drupal 7 and Ubercart 3 installed.
I downloaded the Paypal SDK for PHP 5.2 and verified that it's enough to add
&LOCALECODE=en_UK
in the nvp string.
Where do I have to modify Ubercart to integrate this update?
I tried to modify the uc_paypal.module adding
watchdog('paypal', "uc_paypal_ec_checkout",$variables = array(), $severity = WATCHDOG_NOTICE, $link = NULL);
in all functions containing a $nvp_request array definition, but i can't see any new row in the watchdog table.
Obviously i tried also to add a
'LOCALECODE' => 'en_UK',
row in the definition of the array, but with no effects.
I have the "Paypal express check out" button in the cart, and when i click on it, i obtain the italian version of the Paypal page.
If you have any idea about what file i have to modify and where, please help me.
If you need more info, let me know.
Thank you
I've recently been searching for a solution to this. Some mention being able to change the language of the actual Paypal account, although i've not managed to find that option hidden away with the paypal account setting pages. Plus it is useful for some to provide the payment pages in one language yet still have your account in your own language. So like you I was looking for exactly this.
I've looked through the uc_paypal module code and there doesn't seem to be any easy way to add to the SetExpressCheckout request neatly, so patching the code as you have done seems to be the only way.
The change you have made is the same as mine, except the locale code you are using isn't listed in the PayPal guide I have. I've been referencing the PayPal Express Checkout Advanced Features Guide.
If you use 'US' or 'UK' for your 'LOCALECODE' entry it should work for you. This has worked for me in Ubercart 3.0-rc3, and scanning the latest Ubercart code v3.1 it doesn't look like much has changed so this should work there too.
Note: there are 2 locations relating to the Paypal 'SetExpressCheckout' request which need to have the LOCALECODE added. (One in function uc_paypal_ec_checkout, and one in uc_paypal_ec_form_submit)
Hopefully that helps you.
I hate changing core code and really really really avoid doing it at all costs, and I don't agree with making these types of code changes, but it just wasn't possible on this occasion. If anyone has a better way to do this then please provide it. I think the real answer is to patch the Ubercart uc_paypal module to allow the LOCALECODE to be selected in the settings UI and then incorporate it into the SetExpressCheckout request. Not sure why it isn't currently in there, perhaps Paypal have added this feature after the module was written. I'll look into submitted a patch at some point if others haven't already, but if some one is better placed to make that change/patch then go right ahead! :) I just haven't yet fully familiarised myself with all the Drupal hoops to jump through for getting a patch submitted.