Can anyone point me to the code that CopyCopter uses to scan views for translations?
I considered using CopyCopter as my i18n back end but it has proved too problematic to upgrade it to Rails 4, perhaps when I have more time I'll have a go; So I have chosen to use the tolk gem (https://github.com/tolk/tolk) which is great but it relies on the main yml file to be maintained. This is not an option as there are non technical people working on adding new text plus there will be too many keys to be able to maintain yml files manually.
So I need a tool that will scan views for translation erb tags, check if there is a corresponding tag in the main yml file and add it if one does not exist.
It is my understanding that copycopter has functionality that scans views in this way and I thought I could rip the code out and adapt it for my needs but I have been unable to find the code in either the client (https://github.com/copycopter/copycopter-ruby-client) or the server (https://github.com/copycopter/copycopter-server).
I really want to avoid providing a web interface to manually add keys. That would be too open to mistakes as there will be likely over 8,000 keys.
Any help appreciated or alternative suggestions.
I have found a solution with the i18n-missing_translations gem https://github.com/svenfuchs/i18n-missing_translations. I need to do a bit of work to make them play nicely together but all should be good.
Related
THE PROBLEM
First a little bit of context: I am currently working as a freelancer, developping webapps using Ruby on Rails. Because I am working solo, the need to optimize my workflow is pretty important.
That's why I have always had the same question since I begun working with Rails:
How can I share code/configuration/conventions/tests between my apps?
More precisely, I want to share:
common gems that I always use, with their configuration
common integration tests, to ensure some conventions
common view helpers, test helpers, extensions to the core classes, javascript/sass partials
common files: .gitignore, git hooks, .eslintrc, configuration files of my CI etc
Some concrete examples of what I need in all my apps:
disable turbolinks by default, to add it later if need be
use javascript instead of coffeescript
use slim instead of ERB
install/configure capistrano
install a CSS framework (bootstrap, bourbon + neat + refills)
So far I don't really have the need to share models nor controllers.
I don't want to share behavior or functional components of the system itself, I am not looking for a micro-services architecture.
I have found that so far when creating new applications, all this setup work does take me a lot of time. Also, I would like to apply it retro-actively to existing apps when I add something new.
I have done quite a bit of research, but I haven't found a lot of answers. Many people are trying to share models, but few people seem to want to share a common ground between all their apps. Finding the right keywords may have been the problem though.
It seems to me that Rails is really good at DRY within an application, not so easy when trying to DRY between applications.
POSSIBLE SOLUTIONS
1 - Rails application template
The solution I am using right now, described in the Rails Application Templates guide, using the same API than the Rails generators described in the Creating and Customizing Rails Generators & Templates guide.
That's the solution used by Thoughtbot, with their popular suspenders gem. In the case of Thoughbot though, they have years of experience to draw from, have many employees and their common setup does not change that much.
Pros:
saves a lot of time when creating a new application
really nice API
Cons:
a lot of duplication: all the apps have the same common code, with the problem of this code getting out-of-sync
not retroactive: useless to add a common feature to already created apps
heavy maintenance work: my current workflow is to go through the git log of my apps once per month, and for each commit that could be common to all the apps I have, add it to the application template, and add it to the other apps manually
So far this solution is not that bad, because I only have two applications. But once I will have more, I will suffer from more and more overhead.
A better solution would be maybe to create a generator/rake task for every common new feature, to be able to apply it quickly to existing apps, and call it directly in the application template for new apps.
I haven't tried it though, and I am not really sure it will work. For example what if I want to propagate a one-line change in an existing common file in all the apps?
2 - Rails Engine
I have tinkered a bit with the Rails Engines to share code.
I have not understood from the Getting Started with Engines guide if I should better use a --full engine or a --mountable one for this specific purpose.
Pros:
once I update the gem version, all the changes are made available to the app
DRY: all the common code is in a unique place (the gem)
Cons:
the gems I would like to share are put in the *.gemspec file, which has not as many features as the Gemfile (from what I understand)
overhead caused by the need to update the version of the gem in all the apps, migrate to the new API of helpers, etc
no way to share non-rails files (.gitignore, git hooks, .eslintrc)
This solution has too many important shortcomings.
3 - Hybrid solution: Rails Application Template + Rails Engine
Maybe the best would actually to use both the above solutions.
In the gem share helpers and tests, in the rails template share the gems, their configuration/files and other files (for git, linters, etc)
It is indeed adding more complexity and overhead...
4 - Use git subtrees
Some people use git subtrees to share folders between multiple webapps.
Cons:
one has to share whole folders, not easy to share everything I would need, in their different target directories in the rails app
seems a bit "hacky" to me
Conclusion
Is there another solution than the ones I mentionned above?
What do you think would be the best way to do it?
How about having a blank "Master" rails app in the git somewhere. With all the settings and configurations you'd like to share. When creating a new app from scratch, you can merge the "Master" into it to apply the defaults. When you have an existing app, same thing, just merge and resolve conflicts as needed.This also gives you the ability to override the merged code if needed to.
Few things I can see wrong with this approach though:
Rails application name could cause a lot of headaches
Any updates could cause merge conflicts
I created a tool to deal with this when working in nodejs projects. But the tool is really just a command line tool so you should be able to use it.
https://github.com/tomasbjerre/dictator-builder
It is a concept with creating a dictator that dictates parts of your code base.
Being quite new to rails and currently building a project, i'm begining to be in a situation where my view folder is growing a bit too much
I have for e.g :
/app/
../views/
..../comments/
....../_comment.html.erb
....../_comments_count.html.erb
....../_form.html.erb
....../create.js.erb
....../destroy.js.erb
....../edit.html.erb
....../edit.js.erb
....../index.html.erb
....../index.js.erb
....../new.html.erb
....../show.html.erb
....../update.js.erb
I would definitely prefer to have 2 files :
comments.html.erb
comments.js.erb
And inside of each (like in controller) have a part for each actions.
Currently it seems too much trouble to edit each files, even if they are skinny.
How do you manage your view files ? Is my comments view folder "normal" for a rails project ? Is there some templates engine like handlebar that can help address this problem ?
This is a bad idea. Rails splits up actions into different views so that everything is modular and more easily maintained. There is no way to simply combine everything into a monolithic file and call the parts you want on a per-action basis; that's the point of your controller.
If you're having a hard time editing different files, I wouldn't say that's a problem with Rails behavior but with your development environment. Many IDEs and editors have features or plugins that assist the process of dealing with many files. However, your case is pretty standard for a CRUD view.
In rails 3.1 and beyond, JS files go in the assets/javascripts folder for use in the assets pipeline...which if I read between the lines you'd probably like even less. But aside from that, this looks pretty normal.
Having too much in one file violates the Single Responsibility Principle. Each file should have only one reason to change.
I agree with #rpedroso. Rails sets up these things for a reason. You can choose to disagree with the reason and do it differently; presumably you have a deep understanding of the system and the tradeoffs involved. But doing things differently without knowing the reason is just careless. Rails is so popular because it lays down easy-to-follow conventions which are strongly recommended, because everybody knows what they are and can speak the same language with you. Disregard the conventions at your own peril.
I recommend Michael Hartl's Rails Tutorial as a wonderful intro to Rails.
I've manually created a template and a task on Mechanical Turk. What's the easiest way to now programmatically (in Ruby) create a new task, where:
I reuse the task template I've already created
I upload to MTurk a CSV file with some different data
I can download the raw results CSV programmatically as well
? Is there some Ruby library that already makes this easy, or would I have to dig into the API itself?
I've seen rturk and Turkee, but they seem a little complicated -- I don't actually want my questions to reside on an external site (in the rturk case), and I don't need a Rails app (in the Turkee case -- I couldn't actually get Turkee working with a Rails app anyways).
You might want to check out this fork of rturk. As you can see in the specs it lets you build Amazon-hosted QuestionForms using either XML or a Ruby DSL.
Hope that helps!
I spoke to some folks more familiar with the Amazon MTurk API, and apparently the API doesn't allow to use templates (like in the web UI). Rather, you have to loop through submitting a bunch of individual HIT items.
I have a rails app which contains some fairly generic functionality (eg managing users). I would like to use that common functionality in other rails apps without copying it. The hard part seems to be that this code contains a number of models, controllers and views.
I know that gems and plug-ins allow code to be shared but they seem to apply more to sharing utility and library functionality rather than core parts of an app.
Any advice on how to do this would be greatly appreciated.
We are working with a Rails engine to share functionality between client projects and have gotten quite far with it. The engine contains controllers, models, views, and even routes. It provides core functions needed in each project (access to our in-house content management system) so projects don't have to start from scratch.
Most of the code has been structured in a way that it can be easily extended or overwritten where needed in the projects (mostly by subclassing). It's distributed as gem.
I can't show you code (it's not open-source), but I can point you to some helpful resources:
Rails 3 Plugins - Part 1 - The Big Picture
Rails 3 Plugins - Part 2 - Writing an Engine
Rails::Engine documentation
Plugin Authors: Toward a Better Future
Hope this helps!
Making copies is not always bad. That's why I ask about the reasons you don't want to copy the code.
If you create a 'library', you must ensure that every application will use it in the same manner. Or you have to prepare the 'library' for every possible difference between your applications which use it.
If you share the code, you are adding a dependency to your program. Any change in that shared code will affect more than one application.
Often it's much simpler to copy the code to another application, because then your may apply any modification without thinking about others.
Are you sure that managing users is so generic that you will not make any application-specific changes to it?
What about creating links to the files/directories that have the MVC? That is better than making copies.
i am trying to get my head around the best way to develop an app in ruby on rails
i have a ducument creation system that for each document has multiple associations ie text docs, images, optional accessories etc. I have created this system now to do CRUD.
The next thing i want to do is have each document able to be translated into multiple languages and each document need to be versionized and audited with whats changed when and who dun it etc. Also i need to be able to clone a document for another user so he can then edit it for himself and with all above version and audit features.
I have looked at Globalize2, acts_as_audited, acts_as_versioned, paper_trail and deep_clone and sort of need abit of each !
Please can anyone help me with how or what is the best method of develping this app ? Is there better more suited plugins to use ? can these be used with each other ? and what would be the best process to set this up ?
any help would be most appreciated.
thanks
Rick
thanks askegg for your reply
the thing is acts_as_version does not include your models relations and i need to version each document model along with the children asscociated models ?
So basically if i dont use Globalize my transplated documents will just be other versions but in a different language. Is that correct ? I thought that is what Globalize does ?
thanks alot
rick
It seems you have a grasp of the basic structure you want and have investigated some alternatives.
First pass of my reading: You have a Document model, probably with a polymorphic association to an Asset model. Come to think of it, a Document is just a type of Asset, so one could inherit from the other - perhaps Single Table Inheritance.
From here, add acts_as_versioned to deal with ....well, versioning. This should also be able to give you the differences between various versions, just ensure you record the user_id along with the change.
I am not sure Globalise or i18n will help you here, as they are more geared to translating the web site itself with reasonably static content, not highly dynamic documents such as you're dealing with. I would leave translations to the users and use i18n to present different translations of the web site itself.
Cloning a document should not be too difficult - just create a new Document and populate the information in it. You will probably need a cloned_from_id field and build a self referential has_many in the model.
Well, they are the thoughts off the top of my head.
I was thinking you might treat each image, document, pdf, whatever as separate assets each with their own versions - operating independently of any other. If you need to clone a document and it's children, then you would need to iterate over the children and clone them as well - and their children's children. etc.
Globalise (or any other translation platform) is only really good for set/simple statements. Due to syntax and grammatical issues I would not expect it to be able achieve good translations between languages. Humans are great at that.
It occurs to me that you might want to think about using Git as a document store. This gives you full document versioning with tracking changes. See this presentation for some ideas. Don't worry about all the tech details - just think what it can do for you. The good stuff start about 15 minutes in. The Grit Ruby library can be found here.