Magento - Difference between translate.csv and core_translate - magento

What is the difference between translate.csv translations and the database method via the table core_translate?

Here is part of init() method from app/code/core/Mage/Core/Model/Translate.php
//Loading data from module translation files
foreach ($this->getModulesConfig() as $moduleName=>$info) {
$info = $info->asArray();
$this->_loadModuleTranslation($moduleName, $info['files'], $forceReload);
}
$this->_loadThemeTranslation($forceReload);
$this->_loadDbTranslation($forceReload);
From it you can see that Magento load translation in the following order, i.e. there are three options in Magento to add a custom translation to a text string: module translation, theme translation and inline translation.
Module translation
Module translations are stored in app/locale/languagecode_COUNTRYCODE/ folder in form of csv files, named as Namespace_Modulename.csv All string in extensions that are inside __() method can be translated this way
Theme translation
Strings can be translated inside your theme, for that you just need to set locale via Magento admin area, then create translate.csv in app/design/frontend/<package>/<theme>/locale/languagecode_COUNTRYCODE and put your translated strings inside this CSV
“My Cart”,”My Basket”
“My Account”,”Account”
Inline translation
To enable inline translation you need to log into Admin panel and go to System -> Configuration -> Developer and then find Translate inlined and set Enabled for frontend Yes
All translation made by this method will be stored in core_translate table inside your database. In order to understand better how this method works, check this video out.
The text above is a part of my article on our blog

core_translate table is for phrases that depends on StoreView
/app/design/frontend/YOUR PACKAGE/YOUR THEME/locale/YOUR LOCALE/translate.csv for phrases in YOUR LOCALE language for YOUR THEME. If you change theme this phrases will not be used (translate.csv from new theme will be used).
If phrase is available in database and in csv, then DB phrase will be used.

As I see it, core_translate is useful when you are running magento in a distributed method on multiple servers, and reading from the filesystem just isn't ideal.
I use core_translate with inline translations to handle translated content in CMS blocks. (a mod)
The reason for this is that it is faster to read from the db than to parse a .csv. (I do not know if this is true with caching turned on, but it seemed like the safest route to go)

I dug up this old forum that suggested a few things. Possibly Magento is trying use the inline core_translate approach and push out the translate.csv. However given the forum thread is from 2008 that doesn't seem to be the case. The other suggestion is that some languages use core_translate on the database while some keep the records in a .csv. Possibly the .csv is for local maintainers and the core_translate is for admins. Here's the thread http://www.magentocommerce.com/boards/viewthread/40510/

Related

Can I get entire i18n labels of specific dictionary

I am facing an issue with i18n labels.
My application reads few i18n labels at js frontend using Granite.I18n.get('') function. The entire dictionary gets downloaded as ‘/libs/cq/i18n/dict.{+locale}.json’ as dictated in ‘/etc/clientlibs/foundation/shared/source/init.js’.
Now the en dictionary returns only the custom labels and is small size.
But other languages like fr,the dictionary file is aggregation of all /libs dictionary and is very huge. I noticed this in few other sites also.
tennantco.com
en dictionary - 118 KB
fr dictionary - 1.4 MB
Timewarnercable.com
en dictionary - 1.1 KB
fr dictionary - 1.2 MB
Thermofisher
en dictionary - 3 KB
fr dictionary - 695 KB
Our pain point with this is, cost of caching this heavy file at CDN increases and trying to find a way to reduce CDN cost.
I understand en labels are the key itself. But the ExportServlet is able to filter out the render custom dictionary only for en. Our dictionaries are similar to otb dictionaries under /libs. Then how come ExportServlet treat otb labels under en export?
Is this bug common in all CMS products or specific to Adobe? Also need a solution or workaround to get custom dictionary only for other languages.
The English dictionary is small because English entries are the keys and not the translation. French (and other languages) are big because they contain the key in English and further translation. Also, a lot of keys are only available in translated languages only because the key is used as default translation.
So for French, if you use Granite.I18n.get('Hello world!'), it will return the French translation if it finds it otherwise it will simply return 'Hello World', which doesn't require a translation if the language context is English.
Due to the nature of JS being evaluated on client side, the product is designed to download the full dictionary including the OOTB translation of the product itself as the i18n implementation is not context aware and cannot filter out unwanted translation.
While convenient, this is a limitation and side effect of using Granite.I18n.get('') unfortunately.
Possible Workarounds
Granite.I18n.* can be avoided by using server side i18n libs and rendering only the required translations on server and serving as partial HTML. This may not work for SPA.
If you are using SPA frameworks like Angular(x) then they support i18n factory initialisation which can be hooked into custom servlet response that downloads a filtered i18n. This can potentially be a lot of work and the size can still be a problem if too many terms are translated and dictionary grows large.
Compress, minimise and cache the dictionaries. You can do it with Apache modules or output filters. This will reduce the size and load on traffic but again it's not guaranteed that size will be small for the whole dictionary as the translations grow.
In general, the pages must only render what is required. Using JS to do late translation will force a dictionary download and Granite.i18n does not cater for optimised downloading experience.
I ended up writing a custom implementation as I didnt get much help from Adobe tickets as well on this issue.
OTB dictionary json is rendered by ResourceBundleExportServlet
I created a custom sling servlet that ll prepare and return json similar to ResourceBundleExportServlet
Modified /etc/clientlibs/granite/utils/source/I18n.js to call the custom servlet rather than otb servlet.
Custom servlet is coded to return only specific data dictionary and not all dictionaries.
This solved my problem. Though am not convinced as proper solution. There needs to an otb way of rendering this clean.
We faced the similar requirement to fetch I18n values at client side using Granite.i18n Library
This is what I did.
Created a custom servlet which returns JSON response similar to
ResourceBundleExportServlet.
Loaded the bundle using basename and locale parameter - ResourceBundle resourceBundle = req.getResourceBundle(basename,
pageLocale);
Added sling:basename="basename_constant"' in language specific i18n xml file which resides in /apps/project-name/i18n folder. In my
case, I am setting the value of locale itself ex: "zh_cn".
4.In clientlibs javascript file setting Granite.I18n.setUrlPrefix("/bin/custom/i18n/dict."); to fetch from
custom servlet URL. This doesn't requires modification of OOTB I18n.js
here is an answer that could help you when you are trying to get a specific dictionary: https://stackoverflow.com/a/55656153/14465431
look at the part where is mention the sling:basename
this also works for one site
example:
[sling:Language] > mix:language
mixin
- sling:basename (string)
- sling:basename (string) multiple
http://localhost:4502/libs/cq/i18n/dict.es.[sling:basename-value].json
OTB solution :)

Joomla - how can I count all active instances of specific module type?

As the title suggests my question is pretty simple.
Is there a way to count the total number of active module instances of a specific type/kind in Joomla (with a specific module name)?
I know how to count modules in a specific module position using JModuleHelper::getModules, but that is not what I want.
I simply need to count all active modules instances of a specific type/kind.
Does anyone know how to do this (without having to do a manual MySQL query)?
I do not know if there is an official joomla way, but you can do it by having an sql query looking at
#__modules
table.
Check out this table and you will find out how easy it is.
An example sql would be:
select count(id) from #__modules where module = 'mod_login'
As far as i know there is no joomla method for this. I would recommend (if it has to be done) either
using a crawler to go through all pages of the site counting the instances.
or using a script which goes through the template php files and the database to find all active instances.
Both these methods might not be 100% reliable due to unexpected circumstances (like module being included in article or module included only after a button is clicked on) but could work if you know your site well enough.
Unfortunately there does not seem to be such a function in Joomla.
In my case I needed this to tell me whether or not a instances of this module was > 0 or not.. and my alternative solution was to simply make a module-specific function and then in the module php file check if function is already loaded.

How to serve static profile images in node

This is really more of a "using what method" than a "how-to" question. I am creating a site in NodeJS with Express. So, each user has the ability to upload a profile picture, and my concern is how to route requests for these images. A couple of questions I have are:
Can I use express.static() to serve a default file if a valid one isn't specified? If not, am I going to have to specify a GET route for /img/profileand handle the FS querying there?
How can I find the correct image if multiple file extensions are allowed? (I originally just removed the file extension and they appeared in img tags anyway, is that okay?)
I am currently naming all pictures after their user's name. Looking ahead into the future (for apps I may have to scale), what are normal naming conventions for static user content? Are most stored with a UUID referencing the content in the database?
What else should I take into consideration that I may not have accounted for yet?
First question:
At present, I'd recommend storing your images in a predictable location that can be inferred from some combination of columns or fields in your database entries. One of those fields or columns would be a filename (accounts for different extensions). Then, if they haven't uploaded an image, you just lay down in your view code a reference to the generic "has not set an image" file.
express.static obviously can server static files, but it currently doesn't have a way to serve some other file if the one you wanted isn't there. Because this sounded like fun, I made some modifications to static to support what you request and submitted a couple of pull requests (the feature touched 2 different modules):
In send: https://github.com/visionmedia/send/pull/33
In connect: https://github.com/senchalabs/connect/pull/999
I don't know if those will get included in the project, but if you want to see my forks that have these changes, they are here:
https://github.com/bigohstudios/send
https://github.com/bigohstudios/connect
If this went through, you would mount a static at the root of your profile image files:
app.use(static('<profile image files root>', { fallback: 'anon.jpg'}))
Second question
I generally store the extension in my DB, then when I load the image, I have the correct extension to put into the src attribute on the img tag.
Third question
If you can guarantee unique names, then using those would work. I prefer using the DB id or a UUID as you suggest. It's less intuitive when scanning all the image uploads, but I rarely find myself doing that. I'm usually hunting for a specific image, and I can look up the identifier for that as needed.
Fourth question
You may end up storing the static content outside your app server (e.g. on S3). If that happens, then of course static won't help you.

Parsing Jekyll's Categories

I have created a simple blog based on the Jekyll engine but I need one more function to make the thing really complete.
In Jekyll, parent directories of posts are implicitly 'labels' or 'categories'. So, if I were to create a post under the directory structure
/computers/scm/git
it would end up having 3 labels (computers, scm, git)
In my blog, I have created a few pages:
/computers/index.html
/computers/scm/index.html
/computers/scm/git/index.html
and these pages explicitly list posts in their respective categories such that /computers/index.html displays links to every post in /computers, /computers/sc and /computers/scm/git ... and likewise on down the road. Unfortunately, categories are not compound in Jekyll and so, "/computers/scm/index.html" iterates over the same set of posts as "/sandwiches/scm/index.html" …
Now, I'd like to automatically generate a sitemap listing all the categories, providing links to all of the pages I've created. Jekyll includes a construct "site.categories" that I can iterate over which works just great for all the top level categories. The problem is that when "scm" comes up, there is no "/scm/index.html" - it needs to be "/computers/scm/index.html".
I'm not sure I can fix this behavior - what type of extensions can I write to get both hierarchical categories and automatically generate a site map to my listing pages?
In my wildest dreams, I'd like to be able to tag a post as /a/b/c and have it associated with labels /a, /a/b and /a/b/c and then be able to generate pages that iterate over exactly these sets of posts. I need the site's organization to drill down from general to specific.
Do I need to try a different static generation engine?
You need to use Jekyll's plugins. For categories support in my blog I use one of this.
If you are Github Pages user, you must note that GP does not support plugins because of security reasons. To avoid this, you may use ideas from this blog post.
As an alternative, you can use Octopress, which is Jekyll-based.

how to add more simple products into configurable products using magento API

How can I simply add new simple products incrementally to configurable products?
or do I still need to retrieve the 2 original arrays of the pre-defined configurable product (getConfigurableAttributesData and getConfigurableProductsData) first, append the new arrays and set them again? Is it worked for my case just as the first-time creation?
And if the new simple product owns a new attribute / attribute options, do I also need to create /edit the attribute first before adding?
Thanks in advance!
The API as it stands does not have the functionality to do this.
Your options are:
Extend the API. (Hours of fun)
Do it with Magento methods in your own module or standalone code that includes Mage.php.
SQL script mixed in with your existing API code.
Buy someone's module - (Hope your German is good)
The approach you take also depends on your SKU naming scheme, if you have a simple BASECODE-SIZE-COLOUR type of scheme then the SQL option can work a treat, and in next to no time, but will be heavily scorned on by Magento evangelists.
That means you are probably going to have to write your own code. Here is a very useful site that should help get you started:
http://www.ayasoftware.com/
As well as being able to import configurables (by a variety of means including SQL) there are also snippets of code useful for updating superattribute price differentials. No readymade complete solution, but, you may need to roll your own anyway depending on your SKU naming scheme.
Whilst you are at it you may also want to write some code to find simple products that are not hooked up to anything when they should be, i,e. the ones with no visibility.

Resources