I'm involved in preparing a pre-existing rails application for translation - going through the files under app/views/, finding the text, making a key in config/locales/de.yml (in this case), copying the text into de.yml, and putting t("key") in the view file. Repeat hundreds, maybe thousands of times. This is very tedious.
I don't think it can be fully automated, but the key things I need to do are select the text and give it a key.
So does anyone know of a tool that will automate the rest of the steps? I want to select the text, hit a key combo, type in a key, and the tool will put a key in the de.yml file, append the text, and put t("key") in place of the text that was selected.
My only key requirement is that it should run on Linux. I'm a vim user, but I'll learn Emacs if that is the best way to do it. I'll even install Eclipse if that is the best way ... I imagine that vim or emacs macros should easily be able to do the amount of work I'm asking for.
Anyone? Please?
With a bit of googling, I've managed to find a textmate plugin which would be near perfect if I had a Mac and Textmate. Something similar would be great.
Normally for those cases I use, I18n::Backend::Database (ActiveRecord Adapter for storing translations in the database). This has one major advantage that might also be helpful for your case, I can store translations without the key syntax.
Suppose you have this text <%= link_to 'Das ist ein Link Text', root_url %>
You could transform it to this with I18n::Backend::Database <%= link_to t('Das ist ein Link Text'), root_url %>.
Using this you could create a quick Textmate/Emacs/Vim shortcut to just basiclly wrap the t() around a string.
Does that solve your problem?
Related
I thought this would be something built in and easy to do in Rubymine but I haven't been able to find any references to it let alone possible answers. Maybe I am phrasing my searches all wrong? I want to create a simple ruby script that I can use to transform text in Rubymine. I have to do a lot of snake_case to titleize transformations in my writing of some rails forms. I wish I could highlight some text and right click -> Titleize and have it happen, but Rubymine only does upcase/downcase or snake_case/camelCase conversions. It seems like I should be able to write a simple script like:
require 'active_support'
gets some_string
some_string.titleize
and assign it to a menu item. Any ideas? Right now I open the terminal panel in Rubymine where I have rails c running and copy/paste -> .titleize -> copy/paste.
I don't believe there is a way to do this right now using ruby. The use of RubyMine macros is quite limited, think you could take a look to some simple plugin like CamelCase take it apart and see what they are doing, but that would force you to use Java I guess.
However if you are interested only in the specific case of
snake_case > Snakecase
For that you could install the CamelCase and record a macro and assign it to a any shortcut you like , the macro itself would do this
ALT+SHIFT+U > SnakeCase
CTRL+SHIFT+U > snakecase
ALT+SHIFT+U > Snakecase
Hope that helps.
I started using Vim to do my editing in Ruby on Rails, so I installed the Rails.vim plugin. I really like this plugin, but I have a few issues with it:
I have to type :Econtroller Controller to edit a controller. The same for models (:Emodel Model), etc. If I had a controller named people, it would be much easier to type :ec People and press enter. This would save me 9 characters, not counting every time I have to hit the shift key to capitalize the E!
I don't feel that I should have to capitalize the class name when opening the file as described in bullet #1. For example, if I do want to edit the People controller, I have to press the shift key before I even start to type the name of the class. Then, I type fast enough that I regularly hold down shift too long and People becomes PEople, then Rails.vim RENAMES the file to PEople!
If you have any solutions or suggestions, please let me know. Thank you for your help!
You can use :cabbrev to make exactly the shortcut you're asking for:
:cabbrev ec Econtroller
This way, when typing ec<space>, this will expand to Econtroller<space> anywhere on the command line. See :help abbreviations for more details.
As for capitalization, I don't actually think you need to capitalize the controller. At least on my installation of rails.vim, :Econtroller users works just fine to get me to the UsersController. Maybe you should update your rails.vim plugin?
I'm using:
Rails 3.2x
Spree 1.2
Ruby 1.9.3x
I'm trying to edit the title of one of my pages, and I cannot find where it is getting defined. It is showing up in my base ERB file as 'title', but that name is sufficiently generic to make it next to impossible to find where it is defined.
I have prodded everywhere I can think, I've tried searching for "title =", but nothing is working. I tried calling source_location on it, but that appears to only work on methods.
Any tricks for finding where a variable is defined?
I can't think of an elegant way. A dumb-but-probably-effective way would be to dump stack trace in your erb, then see what those locations are doing and if title is defined there. It has to enter somewhere between the start of program and invoking your erb.
When I can't find something, I use grep -ri some_string . at the command-line to recursively search all the content of the directory.
It's also a good tactic to let your editor search all the source code, since the ones worth using have the ability to search through all files in a directory.
it is created from a mixture of product names, a site config, and something else
An alternate trick is to add a HTML-comment section in your ERB file, and put the pertinent information for the components used to create the title into that section. Then, let the pages be generated and look inside the page's content to determine what table and row ID it is, the site_config filename, etc.
You really should be able to figure it out based on the parts that are concatenated to build the title and then search your database or files. That information isn't magically created out of thin air by Rails; Someone had to tell Rails how to define the title. But, people move on, or they don't document correctly, so try the embedded information trick.
Note: I'm not a RoR developer, so if there is anything inaccurate in the question please correct me.
RoR has its own i18n library. This library (optionally) uses YAML format for the localization files. In these localization files, key-value pairs are used where the value is the translation provided, but these key-value pairs can be within a scope (namespace), here are exapmles:
One example from here - http://guides.rubyonrails.org/i18n.html
pt:
foo:
bar: baz
... the top level key is the locale. :foo is a namespace key and :bar
is the key for the translation “baz”.
And another exapmle from here - http://ruby-on-rails-tutorials.blogspot.com/2010/11/i18n-in-rails3.html
en:
contact:
prices:
show_price: "%{price_dollar}$"
quote: "Coordinator: & quot;Crucifixion?& quot? & lt;br /& gt; Mr. Cheeky: & quot;Er, no, freedom actually.& quot;"
attributes:
created_at: "Created at"
updated_at: "Updated at"
helpers:
submit:
contact:
create: "Order"
update: "Modify"
label:
contact:
name: "Your name"
company_name: "Company name"
phone: "Phone number"
email: "E-mail"
comment: "Comment"
Please check the pointers for better explanation.
An alternative style one can think of is to flatten the scope attributes: for example, in the last quote we can say:
helpers.label.contact.company_name: "Company name"
I believe that the nested style can be very confusing when editing large or deeply nested localization files. And indeed I found a couple of places where this issue is raised:
accessing I18n translations yamls - a thread complaining about this same issue on the rails-i18n group.
The reason of doing it was complications I met with working on huge
piece of data in nested yml files. Having few thousands keys in few
translations files, was making me furious when I needed rename
translation keys, move them to another namespace etc. and had to
scroll a lot, looking and wondering what is namespace of the key.
Also, resolving merge conflicts, checking for missing translations in
other locale files are much easier, when you have and see full key.
And here: https://github.com/henrik/vim-yaml-flattener someone has written a Vim plugin to flatten the file back and forth to overcome the issue.
My question is: what exactly are the advantages of having the nested style. Is there any issues with the flat style that made the developers go with the nested style despite the drawbacks?
I wrote the YAML flattener plugin for Vim.
The main reason for the nested format, to me, is that it's conventional, so any tools or services we may want to use are likely to use that format.
I suppose there is some risk of making typos as you start repeating yourself, and renaming things means renaming them in multiple places – but they're also harder to find to rename, and your editor likely has good tools to rename in batch.
I could come up with more reasons (shorter lines, smaller files, less noisy diffs) but I don't think they're very important.
It's a good question. I'm considering using the flat format most of the time and only converting if I need to use an external tool.
For me, the main benefit of the layout of YAML files is that it's quite easy at a glance to see the relationships between the configuration data. I spent a few years working with Python, which defines scope with white space rather than extraneous characters like {}, etc, so the paradigm is comfortable for me.
Arguably, if you have large yaml files...thousands of keys...then it's probably time to start breaking up the files into smaller, more manageable files. When I am writing code in general and I get a file of ANY sort that is that large, I refactor mercilessly to organize things more intuitively.
Largely this is druthers, I suppose.
I need a way to add text comments in "Word style" to a Latex document. I don't mean to comment the source code of the document. What I want is a way to add corrections, suggestions, etc. to the document, so that they don't interrupt the text flow, but that would still make it easy for everyone to know, which part of the sentence they are related to. They should also "disappear" when compiling the document for printing.
At first, I thought about writing a new command, that would just forward the input to \marginpar{}, and when compiling for printing would just make the definition empty. The problem is you have no guarantee where the comments will appear and you will not be able to distinguish them from the other marginpars.
Any idea?
todonotes is another package that makes nice looking callouts. You can see a number of examples in the documentation.
Since LaTeX is a text format, if you want to show someone the differences in a way that they can use them (and cherry pick from them) use the standard diff tool (e.g., diff -u orig.tex new.tex > docdiffs). This is the best way to annotate something like LaTeX documents, and can be easily used by anyone involved in the production of a document from LaTeX sources. You can then use standard LaTeX comments in your patch to explain the changes, and they can be very easily integrated. If the document lives in a version control system of some sort, just use the VCS to generate a patch file that can be reviewed.
I have used changes.sty, which gives basic change colouring:
\added{new text}
\deleted{old text}
\replaced{new text}{old text}
All of these take an optional parameter with the initials of the author who did this change. This results in different colours used, and these initials are displayed superscripted after the changed text.
\replaced[MI]{new text}{old text}
You can hide the change marks by giving the option final to the changes package.
This is very basic, and comments are not supported, but it might help.
My little home-rolled "fixme" tool uses \marginpar where possible and goes inline in places (like captions) where that is hard to arrange. This works out because I don't often use margin paragraphs for other things. This does mean you can't finalize the layout until everything is fixed, but I don't feel much pain from that...
Other than that I heartily agree with Michael about using standard tools and version control.
See also:
Tips for collaboratively editing a LaTeX document (which addresses you main question...)
https://stackoverflow.com/questions/193298/best-practices-in-latex
and a self-plug:
How do I get Emacs to fill sentences, but not paragraphs?
You could also try the trackchanges package.
You can use the changebar package to highlight areas of text that have been affected.
If you don't want to do the markup manually (which can be tedious and interrupt the flow of editing) the neat latexdiff utility will take a diff of your document and produce a version of it with markup added to visually display the changes between the two versions in the typeset output.
This would be my preferred solution, although I haven't tested it out on large, multi-file documents.
The best package I know is Easy Review that provides the commenting functionality into LaTeX environment. For example, you can use the following simple commands such as \add{NEW TEXT}, \remove{OLD TEXT}, \replace{OLD TEXT}{NEW TEXT}, \comment{TEXT}{COMMENT}, \highlight{TEXT}, and \alert{TEXT}.
Some examples can be found here.
The todonotes package looks great, but if that proves too cumbersome to use, a simple solution is just to use footnotes (e.g. in red to separate them from regular footnotes).
Package trackchanges.sty works exactly the way changes.sty. See #Svante's reply.
It has easy to remember commands and you can change how edits will appear after compiling the document. You can also hide the edits for printing.