I am translating my application through *.po-files, but the command
mix gettext.extract --merge
generates options only for hardcoded strings.
I have read in documentation that I can't edit *.po-files manually because they are overwritten every time.
How can I translate errors that come from changeset validations and so on?
dgettextfor errors is called in web/views/error_helpers.ex
I'm not sure if these get extracted and merged into errors.po, but that's where you'd likely put them manually if they do not.
Related
I've edited some existing visual queries of Blog 4.0 application and when I was debugging it - it worked perfectly. But then on page it stopped working. Any attempt to use key with Data like Data["Posts"] raises System.Collections.Generic.KeyNotFoundException. App.Query["Blog Posts List"]["Posts"] returns something, but any attempt to access its fields raises another exception (don't remember the name, but it said that there's no such member inside that object).
I didn't rename queries, I didn't change application settings. I just edited logic of 2 queries. I renamed 1 wiring endpoint name across 3 queries in whole chain.
How do I debug it? How can I see what does cshtml receive from database so I don't guess and put my crystal ball away?
In general, App.Query["Name of Query"] will get you the streams of data. You usually need to convert it using AsDynamic() or AsList() to something you can work with.
This should help some; What is Data?
If you're just running into problems with field names, you probably forgot the AsList or AsDynamic, just like #accuraty-jeremy mentioned.
For real debugging, go to insights, you'll see what happens - but in your case it probably won't help, because your working with an object that's not dynamic (so doesn't support .FirstName) until you AsList/AsDynamic it.
My bad: I confused two different files - _List.cshtml and _List Paging.cshtml. So I was searching for an error in the code of wrong file.
Magento seems to be using "Happy go Lucky" error handling, where all errors in xml files will just cause the xml config file to be ignored. And missing/wrong tags will just be ignored too, sometimes causing Magento to skip parts of the xml file.
But is there any way(A log file or something) which shows exactly what part of the config files Magento skips, and which tags are unknown/wrong. Using Magento 1.6 if that matters.
From what I have seen in Magento, it will throw out the entire XML file if there is invalid XML in it - broken/mismatched tags, erroneous characters, etc. I think it would be somewhat impossible for a xml parser to do any sort of a decent job parsing this out - that's the goal of XML. If my configuration isn't loading, the first think I like to do is go and perform a wellformedness validation on the code, which will show me if I have a problem there.
If there is references to invalid classes, usually it will break. Layout XML is different - it will ignore the block and continue on, which can be a real pain to troubleshoot.
So, to answer your question - no, there isn't a native way to do this. The best way, IMO, is to go and validate it at a third party.
There is logging in Magento, to enable it:
Go into your Admin Panel, then System > Configuration > Advanced > Developer
Under Log Settings ensure Enabled = Yes
This will create two separate logs in magento root/var/log (in my case /var/www/html/var/log)
Exception.log will hold any errors created using Mage::LogException($e)
System.log will hold any logging created using Mage::Log('message')
You can also create your own log files...if you so wish by
Mage::Log('message', null, 'my.log');
This will create a my.log file in the var/log directory.
FYI - I believe the reason Magento handles configuration files in this manner is to protect the rest of the system from an issue with a single extension.
I have a CakePHP ticketing app where I am using Revision Behavior to keep revision history of each tickets. The problem I have using this behavior is, it does not display validation error messages. Here is the line I have added in the model.
public $actsAs = array('Revision' => array('limit'=>10));
When I comment this line, it displays error messages and otherwise it does not. Also, when I debug it using x-debug, I see validationErrors variable is set and has all error message values set properly.
Please shed some light here.
Edit: I am using Cake 2.1
First, be sure to get the last version of this behavior : http://alkemann.googlecode.com/svn/trunk/models/behaviors/revision.php
for integration in CAKE 2.X, the problem comes from line 980 in the createShadowModel() function:
$Model->ShadowModel->alias = $Model->alias;
The behavior gives the same alias to the base model and its shadowmodel it will save in the _revs table and that seems to mess up the validation messages.
The problem is that this behavior is loaded automatically when you access your model, and the createShadowModel() function is called even if your input doesn't validate.
One of the solution would be to comment out this line from createShadowModel() and then to add it only to every function in the behavior that will make an operation in the DB . There is surely a better way than that, like detecting in the setup() if there is need to go further to initialization, but couldn't find how to do it. So that's my first step towards at least allowing to use this behavior in Cake 2.X.
There are a few things that could be happening here. Too much for one to simply tell you what is happening since we don't have any of your code. However, I am pretty certain that this behavior, being that it was written in 2008, will have issues with CakePHP version 2.1, which just released its first alpha. There have been a lot of changes to the infrastructure of Cake that could cause this not to work. I'd say this would probably work with version 1.3 and definitely with 1.2, but getting support for 2.1 probably won't happen without updates.
That said, this is a behavior, which should only alter model code. So, there should be not impact (theoretically) on your view. Are you sure you are using the proper conventions in your code to display errors (even though commenting it out changes displayed messages).
I'd look for a 2.0+ compatible version of the behavior. Or, you could throw the code on Github and start to port it yourself. You may get some help from some Cake people.
Short description
I'm getting used to CakePHP right now and am wondering about how to get more debug-information about what is happening inside the framework.
Let me please explain my situation a little more detailed
As you know CakePHP does a lot for you without putting you into the need to write additional code. One example is the handling of models.
I just created a model User and added validation-rules (no other methods). As described in the API methods like save will just work.
After that I created the needed controller and view to add a new user. When I try to add a user from the view I just receive the flash-message The user could not be created. Please, try again. No validation-violations are flashed.
I also did set the debug-level to 2: Configure::write('debug', 2); but do not receive any errors. The error.log inside \tmp\logs is also empty.
I really do want to learn how to solve those issues in the future.
So what else can I do to debug / display inner processes of cake?
Thank you very much for your help!
DebugKit is an official plugin that gives you lots of information on the request, queries and variables produced by Cake:
https://github.com/cakephp/debug_kit
You can also use trace() and other methods in the Debugger to show what is being executed in the background:
http://book.cakephp.org/2.0/en/development/debugging.html
Use a PHP IDE with an integrated debugger. That will allow you to follow execution line by line as it is executed and even inspect variable values as you go. Netbeans is a free one.
I have a Managed Object Context to which I add two different SQLite stores. I use Configurations in the Mananged Object Model to assign certain entities to one store and other entities to the other. The Configurations are called "UserDB" and "MainDB".
Everything works okay until I try to use automatic migration. After creating a new Managed Object Model version, and adding a new attribute to one of the entities in the UserDB Configuration, I get an exception when adding the old version store (for the UserDB related store) to the store coordinator: 'Model does not contain configuration 'UserDB'.' I can find no hits for this error on Google. Anyone out there using multiple stores with Configurations? Anyone have an idea what I might be doing wrong?
The stack looks like this:
objc_exception_throw
-[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:]
-[NSStoreMigrationPolicy sourceModelForStoreAtURL:metadata:error:]
-[NSStoreMigrationPolicy(InternalMethods) _gatherDataAndPerformMigration:]
-[NSPersistentStoreCoordinator addPersistentStoreWithType:configuration:URL:options:error:]
-[MyAppDelegate persistentStoreCoordinator]
This looks like a bug with migration+configurations. I was able to work around the problem by going through the same motions and passing nil for configuration when calling addPersistentStoreWithType. The migration happens, and then I can make a new persistent store coordinator and add the stores again with the proper Configuration string arguments.
This is the second configuration related bug I've run into. Not a well tested feature apparently.
I had the same problem. The fact pattern was identical and the error message the same. It turned out, however, to be the result of my own mistake.
Let's say the old model was Blah.xcdatamodel and the new Blah 2.xcdatamodel. I had started making changes to Blah before realising my mistake and creating Blah 2. I then used my version control system (Git) to revert to the old Blah and then recreated Blah 2. Everything looked right. But I must have done something wrong in the reversion process, because when I thought to double check that Blah.xcdatamodel in my current project folder was really the same as Blah.xcdatamodel in the project folder I used to build the previous version of the app (fortunately I always keep a zipped archive of the project folder for each released version as I don't fully trust version control systems), I found that they were in fact different, albeit that they looked identical in XCode. The file size was different, for instance.
I substituted the old Blah into my current project folder, and lo and behold it all went perfectly, without any need for the workaround described by Ken.
I am not saying that Ken had necessarily made a similar mistake, but if you do encounter this message it is at least worth confirming that the model you are migrating from is REALLY the model that was used to create the data in question.