I can 't seem to find an example of the format Magmi wants for the csv data. Could someone please provide a one-line example of a successful product import?
Edit:
Magmi Wiki: http://sourceforge.net/apps/mediawiki/magmi/index.php?title=Main_Page
actually, it will depends on many factors (if you're importing images, creating categories, relationing configurable products, etc...), so there isn't a correct answer to your question.
But you can export a csv file of all magento's sample products (system -> Import/Export -> Dataflow - Profiles -> Export All Products) and take that as a reference, Magmi will understand it.
Notice that in order to use some parameters (for example the visibility values "Not Visible Individually", "Catalog and Search", etc...) as strings you'll have to use Magmi's "Generic Mapper" plugin.
I have spent the last month using it intensively, and must say I love it. If you have a more specific question don't hesitate to ask, it's still fresh in my brains :)
HTH
The trick is that Magmi often has it's own column names and requirements for field values. So, if you have a standard Magento import CSV, certain columns and fields will not get parsed.
for example, on a typical import magento uses "config_attributes" & "associated" as column names. For Magmi, you must use "configurable_attributes" and "simples_skus" respectively
As for the field requirements, the fields must often be in integer format. Magmi provides a "Generic mapper v0.0.6a" plugin that takes care of most of the standard mappings. For example, rather than using strings to assign "visiblity", magmi requies this value to be integer. The Generic mapper uses a configuration file that takes care of this:
visibility.csv
"Not Visible Individually",1
"Catalog",2
"Search",3
"Catalog, Search",4
Magmi is a wonderful addon - and really powerful with the plugins.
For information on it I'd recommend using the wiki at http://wiki.magmi.org/index.php?title=Main_Page.
For the csv, look at http://wiki.magmi.org/index.php?title=Import_-_CSV_datasource.
But as OSdave said, it is really powerful, and doesn't work with one csv format since you can remap and manipulate the fields anyway.
Hope that helps a little.
Related
I have Magento 1.8.1.0. Recently I've installed Russian pack, the result wasn't appropriate enough, cause some phrases on frontend remained in English
I know there's handy way to translate Magento using cvs-files.
The question is where I can find proper cvs-file? Does installed theme concerns translation some how? I know I'm asking newbie questions, I've read several posts, but I haven't made up my mind how to translate Magento.
Many thanks in advance.
Hope you are doing well,
As i have gone through your question that you want to translate your websites front end in Russian if user has selected the language Russian.
For this you are required to work out the translate.csv files which will be available in your theme Package.
Example : app/design/frontend/default/SecuareWeb/locale/de_DE
In the locale folder you will find the folder for Russian language open that folder and you will find the file where you are required to add the required translation text in it.
How to add translation text in translate.csv file is given below.
Example:
"This is the demo of translation in Russian","Это демо-трансляции на русском языке"
And one thing i would like add is that make sure your front end .phtml files must contain the text in $this->__("Example");. If you have added all the text like this then only then it will allow you for translation other wise it will not translate a text.
Hope this might be use full to you !!!
Waiting for your valuable comments in regards to your Question !!!
There are different ways to achieve translation in Magento so you can find multiple directory containing static csv files and also a database table.
All the modes have same structure: key/value. For example: "String to translate","String translated".
Inline Translation (database table: core_translate):
following best practices in Magento, you should use inline-translation aka database saved translation in rare cases. It is harder to mantain and can be buggy. It has first precedence, so any translation you do via inline translation will override the other 'modes'.
Theme level Translation (file in app/design/frontend/your_package/your_theme/ru_RU/translate.csv):
you can place any string to be translated in the translate.csv. It has second precedence.
Locale translation (file in app/locale/ru_RU/Module_Name.csv):
the suggested way to do translation as it will keep translation separated by each module and is easier to maintain. For example: Mage_Catalog.csv etc.
Each module in Magento can specify its csv file containing translation and sometimes the same string has different modules trying to translate, so if your translation does not work check between multiple file by a quick editor search. It will be overridden by the two above modes.
Note:
Magento will load all the csv files and build up a giant tree and caches it. So before scratching your head because the string is not translated as you wished in the frontend:
1. clean the cache.
2. check for any same key string which comes after your translated string. For example: in the same csv Line 100 will override Line 1 if the key string are the same.
3. check for any same key string in the mode which has higher precedence. For example: inline translation will override any csv based translated string.
It may be easier for you to go to the admin backend System -> Configuration -> Developer and switch "Translate Inline" "Enabled for Frontend" to "Yes".
Then, refresh the frontend and you can change the translation directly at your web browser.
The translation is saved in the database table core_translate just for the case you want to do it in a test environment and copy the translation later on to the production.
Take care that without client restrictions (System -> Configuration -> Developer) everyone will see the translation options.
btw. You may need to clear the cache and refresh the webpage in order to see your changes.
Our application (rewritten to wxWidgets) should use mostly common strings from the language catalogs (.mo). But it also uses panels with texts that are tailored for the customer via the configuration file. The configuration files are generated for the customer, so it could be (say) another catalog file. However...
Can one catalog file contain replacements (overwrites) for the default strings from the basic catalog?
Or, can the structure with strings loaded from the catalogs (.mo) be modified programmatically? (I mean if it can be done using some recommended way in the sense "Don't pee against the wind".)
Is there any standardized mechanism for storing the user-defined strings (via the same application)?
Thanks for your time and experience,
Petr
You can load several catalog files by using wxLocale::AddCatalog. The translations are searched for in all the catalogs loaded. If two catalogs contain the same string, I assume the translation is taken from the catalog that was loaded first. I didn't test though, admittedly. Anyway, if this is the case, you need to make sure the custom catalog file is loaded first. That way the translations in the custom catalog have precedence, and effectively they replace the default translations.
I am trying to use following code with latest Magento V1.7.1:
http://www.sonassi.com/knowledge-base/magento-kb/mass-update-stock-levels-in-magento-fast/
I updates stock quantities from CSV file.
It works fine with the following fields:
"sku","qty"
"prod1","11"
However, it does not work, if there are any additional fields.
I tried:
"sku","qty","is_in_stock"
"prod1","11","1"
then qty gets updated, but is_in_stock or any other fields that follow qty are not being imported into the database.
I tried to switch fields and tried the following:
"sku","is_in_stock","qty"
"prod1","1","11"
and now is_in_stock gets updated, but qty does not.
Instruction say to use a minimum of two plus any of additional fields listed, but it does not work.
Would you be able to share updated code?
Thank you.
I don't know the mentioned import extension, but most probably it'll use fgetcsv() calls to read the CSV file, like Magento does.
The fgetcsv() function uses the regular (", Shift+2) double quote as enclosure delimiter by default.
If you really copied the CSV lines 1:1 from your CSV file into this post, containing up to three different enclosure delimiters (“, ” and ") per line, then fgetcsv() has no chance to properly return the field values.
To fix this, just replace all double quotes in your CSV file with the regular one, save and import again.
Remember that depending on your os, the line endings aren't always the same. Windows editors have a nasty habit of adding an extra Carriage Return at the end of each line (learned this the hard way when I wrote a Linux parser for this sort of job in C++). Best check your csv by using something like Notepad++ to see what's at the end of each record.
I'd recommend using Magmi for simple updates such as this. It takes a little effort to set-up (but has very solid documentation to walk you through the process), but once done, is fast, stable and contains a lot of additional plugins that you can use for more functionality than just stock updates in the future.
The St. Louis Federal Reserve Bank has a great set of data available on a variety of their web pages, such as:
http://research.stlouisfed.org/fred2/series/OILPRICE/downloaddata?cid=32217
http://www.federalreserve.gov/releases/h10/summary/default.htm
http://research.stlouisfed.org/fred2/series/DGS20
The data sets get updated, some as often as daily. I tend to have an interest in the daily data (see the above settings on the URLS)
I'd like to import these kinds of price or rate data streams (accessible as CSV or Excel files at the above URLs) directly into Mathematica.
I've looked at the documentation on Importing[] but I find scant documentation (actually none) on how to go about something like this.
It looks like I need to navigate to the pages, send some data to select specific files and formats, trigger the download, then access the downloaded data from my own machine. Even better if I could access the data directly from the sites.
I had hoped Wolfram Alpha might make this sort thing easy, but I haven't had any success.
FinancialData[] would seem natural for this sort of thing, but I don't see anyway to do it. Financial data has lots of features, but I don't see a way yo get this sort of thing.
Does anyone have any experience with this or can someone point me in the right direction?
You can Import directly from a URL. For example, the data from federalreserve.gov can be obtained and visualized as follows.
url = "http://www.federalreserve.gov/datadownload/Output.aspx?";
url = url<>"rel=H10&series=a660e724c705cea4b7bd1d1b85789862&lastObs=&";
url = url<>"from=&to=&filetype=csv&label=include&layout=seriescolumn";
data = Import[url, "CSV"];
DateListPlot[data[[7 ;;]], Joined -> True]
I broke up url for convenience, since it's so long. I had to examine the contents of data before I knew exactly how to plot it - a step that is typically necessary. I'm sure that the data from stlouisfed.org can be obtained in a similar way, but it requires the use of an API with key to access it.
As Mark said, you can get the data directly from a URL. Your oil data can be imported from a different URL than you had:
http://research.stlouisfed.org/fred2/data/OILPRICE.txt
With that URL, you can do this:
oil = Import["http://research.stlouisfed.org/fred2/data/OILPRICE.txt",
"Table", "HeaderLines" -> 12, "DateStringFormat" -> {"Year", "Month", "Day"}];
DateListPlot[oil, Joined -> True, PlotRange -> All]
Note that "HeaderLines"->12 option strips off the header text in the first 12 lines (you have to count the header lines to know how many to remove). I've also specified the date format.
To find that URL, do as you did before, but click on a data series and then choose View Data from the menu on the left when you see the chart.
The documentation has a short example on extracting data out of a webpage:
http://reference.wolfram.com/mathematica/howto/CleanUpDataImportedFromAWebsite.html
Of course, what actually needs to be done will vary significantly from page to page.
discussion on how to do this with your API key here:
http://library.wolfram.com/infocenter/MathSource/7583/
the function is based on the API documentation. I haven't looked at the code for a couple of years and from memory I put it together rather quickly but I have used it regularly for over 2 years without problems. Here is an example for monthly non seasonally adjusted retail sales from early 1992 to now:
wolfram alpha also uses FRED data so you could use that as an alternative to direct import but it is more tricky to get the query right. I prefer to use FRED directly. Also from memory the data is only available on alpha the day after the release, which is not what you would typically want.
does anybody has experience in exporting data as a FITS file with custom Metadata (FITS header) information? So far I was only able to generate FITS files with the standard Mathematica FITS header template. The documentation gives no hint on whether custom Metadata export is supported and how it might be done.
The following suggestions from comp.soft-sys.math.mathematica do not work:
header=Import[<some FITS file>, "Metadata"];
Export<"test.fits",data ,"Metadata"->header]
or
Export["test.fits",{"Data"->data,"Metadata"->header}]
What is the proper way to export my own Metadata to a FITS file ?
Cheers,
Markus
Update: response from Wolfram Support:
"Mathematica does not yet support Export of metadata for FITS file. The
example are referring to importing of this data. We do plan to support
this in the future..."
"There are also plans to include binary tables into FITS import
functionality."
I will try to come up with some workaround.
According to the documentation for v.7 and v.8, there is a couple of ways of accomplishing what you want, and you almost have the rule form correct:
Export["test.fits", {"Data" -> data, "Metadata" -> header}, "Rules"]
The other ways are
Export["test.fits", header, "Metadata"]
Export["test.fits", {data, header}, {{"Data", "Metadata"}}]
note the double brackets around the element labels in the second method.
Edit: After some testing, due to prodding from #belisarius, whenever I include the "Metadata" element, I get an error stating that it is not a valid export element. Also, you can't export a "RawData" element, either. So, I'd submit a bug for two reasons: the metadata isn't user settable which is vitally important for any serious application. At a minimum, the user should at least be able to augment the default Mathematica metadata. Second, the documentation is woefully inadequate in describing what is a "valid" export element vs. import element. Of course, I'd describe all of the documentation for v.6 and beyond as woefully inadequate, so this is par for the course.
Mathematica 9 now allows export of metadata (header) entries, which are additive to the standard required entries. In the Help browser, search "FITS" and there is an example that shows this (with Export followed by Import to verify).