According to Laravel Docs: https://laravel.com/docs/5.1/localization#overriding-package-language-files
for example, if you need to override the English language lines in messages.php for a package named skyrim/hearthfire, you would place a language file at: resources/lang/vendor/hearthfire/en/messages.php.
I currently have the package activewebsite/enterprise-entity package that I am including in my project. It contains a language file:
vendor/activewebsite/enterprise-entity/src/resources/lang/en/phone.php
This file contains translations for types of phone numbers:
'phone_1' => 'Home',
'phone_2' => 'Work',
'phone_3' => 'Mobile',
'phone_4' => 'Office',
'phone_5' => 'Fax',
'phone_6' => 'Fax 2',
'phone_7' => 'Home 2',
'phone_8' => 'Direct',
Following the example above, I attempted to override this file by creating the following directory:
resources/lang/vendor/enterprise-entity/en/phone.php
containing an additional phone number specific to this project:
'phone_9' => 'Rapid Rewards Text Alert Number',
But the the translation does not come through to the front-end. The only way I've been able to get the translation to appear is to edit the language file within the enterprise-entity package.
I found this thread: https://octobercms.com/forum/post/localication-problems-where-to-overwrite-octobercms-lang-settings-in-general
Where another user seems to be having a similar issue, but it is suggested that they use the directory structure:
/lang/{locale}/{vendor}/{plugin}/lang.php
so I attempted
/lang/en/activewebsite/enterprise-entity/phone.php
with no luck.
Can anyone tell me what I may be getting wrong here? I've attempted running a php artisan optimize after each change to see if that could clear things up, but no luck.
Thanks!
Turns out the folder structure needs to use the NAMESPACE for the package, camelcase, not follow the same naming convention/directory structure as in the package or in the docs. So, for my example, the namespace used for the enterprise-entity package is EnterpriseEntity, camelcased would be enterpriseEntity.
The correct directory structure would be:
resources/lang/vendor/enterpriseEntity/en/phone.php
From Laravel Official Documentation
Overriding Package Language Files
Some packages may ship with their own language files. Instead of changing the package's core files to tweak these lines, you may override them by placing files in the resources/lang/vendor/{package}/{locale} directory.
So, for example, if you need to override the English translation strings in messages.php for a package named skyrim/hearthfire, you should place a language file at: resources/lang/vendor/hearthfire/en/messages.php. Within this file, you should only define the translation strings you wish to override. Any translation strings you don't override will still be loaded from the package's original language files.
Related
I am busy making a sublime text plugin/package that will ease development of lua scripts in my workplace.
We have several lua files with different extensions depending on their purpose. I want ST3 to give the proper lua syntax to these files.
I know you can set ST3 to remember syntax for a specific file extension and this is saved as a (in my case) Lua.sublime-settings file in AppData\Roaming\Sublime Text 3\Packages\User
However, if I put this file in my new plugin's folder, it's ignored.
Am I doing something wrong or is what I want not possible?
This doesn't work because syntax specific settings are only loaded from the package that defines the syntax and from the User package (so the user can customize them).
The following is a quote from the official documentation on settings:
Settings files are consulted in this order:
1. Packages/Default/Preferences.sublime-settings
2. Packages/Default/Preferences (<platform>).sublime-settings
3. Packages/User/Preferences.sublime-settings
4. <Project Settings>
5. Packages/<syntax>/<syntax>.sublime-settings
6. Packages/User/<syntax>.sublime-settings
7. <Buffer Specific Settings>
The only places where <syntax> is referenced is from the package itself and from the user package.
If I had to guess, I would say that this is because outside of the original package author that defined the syntax, all other settings would be considered user customizations, and those settings need to be in the User package (specifically in the root of it) to ensure that they're loaded last.
A simple (but undesirable) solution would be to document for the user that they have to take this step manually.
Another approach would be to add some plugin code that extends the settings when your plugin is loaded:
def plugin_loaded():
settings = sublime.load_settings("Lua.sublime-settings")
extensions = settings.get("extensions", [])
if "blarb" not in extensions:
extensions.append("blarb")
settings.set("extensions", extensions)
sublime.save_settings("Lua.sublime-settings")
If you go this route you may want to include an extra sentinel setting somewhere (in settings specific to your package or some such) that says if you did this or not instead of just forcing the setting in as the example above does.
In practice you would then check if you've set that sentinel or not instead of forcing the extension in, so that if the user decides to use some other syntax for your files you're not forcing them into the Lua syntax.
It's also possible to define your own syntax that just embeds the standard Lua syntax, which allows this to Just Work⢠without having to write any code or have the user do anything:
%YAML 1.2
---
name: Blarb
scope: source.lua
file_extensions:
- blarb
contexts:
main:
- include: scope:source.lua
When you do this, the scope in the file will still be source.lua because that's what the scope in the syntax file says. and the status line will set the syntax name to Blarb. You could modify either of those to change the top level scope or displayed name, if desired.
An example would be to change the scope to source.blarb so that you could create key bindings/snippets that only apply to Lua files of your specific variant.
A potential downside/feature of this is that since the name of the syntax specific settings comes from the name of the file that provides the syntax, if the user has any Lua specific settings, they won't apply to your Blarb files by default.
Similarly anything that's specific to Lua by checking for a scope of source.lua won't work in Blarb files for same reasons, which may or may not be an issue.
I am trying to follow the steps to change the Gridworld appearance according to this. I've already imported source code for my gridworld jar file; ie. I can go and look at Bug.class or Gridpanel.class if I wanted to. However, I can't edit these files to produce the results that that pdf suggests. How do I do this? Did I import the source code incorrectly?
I don't think you can edit an external resource like gridworld.jar. You are going to need to create 4 new packages:
actor
grid
gui
world
Then copy the class files from gridworld.jar packages into your corresponding ones. Now you can edit the files. Make sure you include any miscellaneous files that might also be in the gridworld.jar packages, their important.
With your own packages you no longer need the gridworld.jar external resource, and there is a difference in your import statements. Instead of
import gridworld.actor.Actor;
Do this:
import actor.Actor;
Note: You will need to change all of the import statements in the new package classes to reference the other new packages. I believe that there were also some errors, not project breaking, but I just added suppressors.
I'm planning to do a program with Lua that will first of all read specific files
and get information from those files. So my first question is whats the "my documents" path name? I have searched a lot of places, but I'm unable to find anything. My second question is how can I use the first four letters of a file name to see which one is the newest made?
Finding the files in "my documents" then find the newest created file and read it.
The reading part shouldn't be a problem, but navigating to "my documents" and finding the newest created file in a folder.
For your first question, depends how robust you want your script to be. You could use Lua's builtin os.getenv() to get a variety of environment vars related to user, such as USERNAME, USERPROFILE, HOMEDRIVE, HOMEPATH. Example:
username = os.getenv('USERNAME')
dir = 'C:\\users\\' .. username .. '\\Documents'
For the second question, there is no builtin mechanism in Windows to have the file creation or modification timestamp as part of the filename. You could read the creation or modification timestamp, via a C extension you create or using an existing Lua library like lfs. Or you could read the contents of a folder and parse the filenames if they were named according to the pattern you mention. Again there is nothing built into Lua to do this, you would either use os.execute() or lfs or, again, your own C extension module, or combinations of these.
In Delphi there is an option VersionInfo->Language->Locale ID when viewing project properties.
I was wandering how to set such property for a program being compiled under Free Pascal.
Any solution is welcome: command line argument or preprocessor directive such as {$key value}; equivalent to Delphi.
If you can build your projects using *.lpi files then I would try to add the following into your project's Project.lpi file. In the following snippet is shown how to set the project's locale ID (for Windows platform) to 0405 (Czech).
<?xml version="1.0"?>
<CONFIG>
<ProjectOptions>
...
<VersionInfo>
<UseVersionInfo Value="True"/>
<Language Value="0405"/>
<StringTable ProductVersion=""/>
</VersionInfo>
...
</ProjectOptions>
...
</CONFIG>
Or if you are using Lazarus IDE then you might use to Delphi very similar settings tab which you can open from Project / Project Options ... and as in Delphi go to Version Info where is the Language selection combo box available if you include the version info into the project.
Not 100% sure this will work, feel free to vote me down if this doesn't work.
Lazarus will inherit the locale settings it starts with.
You can set the locale info prior to starting Lazarus in Linux/OS X using the command line:
export LC_CTYPE="pt_BR"
export LANG="pt_BR"
export LANGUAGE="pt_BR"
./lazarus
Your compiled application should inherit these settings.
The answer is inspired by this workaround to an error has since been fixed.
I recommend you have a look at the fpc forum as well and ask the question there.
Don't forget it include details like the platform (Linux/Windows/OS X) and the exact version of FPC and Lazarus you are using as well as the actual Locale that you want.
Better answer
From: http://forum.lazarus.freepascal.org/index.php/topic,5924.0.html
Finally, I managed to find a simple and effective way to make my application localizeable. It uses just one unit and no code.
1. Add unit "defaulttranslator" to your uses list.
2. Enable "i18n" in "Project Options" and set "PO output directory" to "locale" or "languages". You can put translation files right into application folder, but that would just make a mess. Don't forget to create an appropriate folder.
3. Add components to the form. If you already have all components on your form, you'll have to move it a little bit, so it's modified.
4. Save your project.
5. Now there should be .po files in your "locale" or "languages" folder. For different languages files should be copied and renamed like so "project1.XX.po", where XX is language code (e.g. "en", "de", etc.).
6. Translate .po files with translation software, and generate .mo files. I suggest to use POEdit.
7. Run your application, and the translation to be used will be chosen by your regional locale settings. If you need to test other language - just start your application with following command line parameters - "-l XX" or "-lang XX", where XX is a language code.
This method is not very versatile, but it translates resource strings and LCL component properties.
When I'm in an html.erb file, I get no snipMate snippets.
I would like both HTML and Ruby, or just HTML would be fine,
How would I do this?
Would I need to write a set of snippets?
If so, is there a way of pulling in existing snippets without copying them?
Is there a way of telling vim to go into html mode when it sees .html erb?
You can use an autocmd to set the filetype to html when opening a ".html.erb" file. This could have unwanted side effects for plugins that work for ".erb" files.
autocmd BufNewFile,BufRead *.html.erb set filetype=html
You can also load more than one set of snippets by using a dotted filetype:
autocmd BufNewFile,BufRead *.html.erb set filetype=html.eruby
See :help snippet-syntax in the snipMate help for more info.
Snippets are stored in directory called snippets somewhere in your ~/.vim folder.
If you look there, there is usually one file per filetype, there is a c.snippets, a ruby.snippets, so it seems what you have to do is to create an erb.snippets there with what you want.
Eventually you could copy the content of ruby.snippets and html.snippets into your new erb.snippets.
Alternatively you can search on github, some people have posted their own erb.snippets configuration. For example, there is a nice collection there :
https://github.com/scrooloose/snipmate-snippets
The best thing would to try first to open a snippet file and look at the syntax, it is pretty easy to create your own snippet depending on what you use the most.
I am currently on a promoting tour for UltiSnips on StackOverflow. UltiSnips supports extending other file types, your erb.snippets would look like this:
extends html, ruby, rails
snippet temp "A snippet only in Erb"
erb rules ${1}
endsnippet
A conversion script for snipMate snippets is shipped with UltiSnips, so switching is easy.
I used the autocommand method to the set the filetype, but then I got html syntax errors for things like this:
<%= image_tag("logo.png", :alt => "Sample App", :class => "round") %>
The last two angle brackets would be highlighted in red, which drove me bonkers. So, I created a symlink called eruby.snippets that points to html.snippets. That worked like a champ and now I don't have to make changes in two places. I also have an eruby-rails snippet directory for non-html eruby snippets.
This is on a Mac OS X system. Note that an alias won't work. You need to hit the terminal and use the ln command. Not sure about doing this on a Windoze system.
You can assign multiple snippets scopes to a single filetype. (I've found that altering the filetype tends to break some syntax highlighting).
You can check that the filetype for erb files is indeed 'eruby' with:
:set filetype?
If you're using the maintained fork of snipmate, it looks like you'll want both the eruby.snippets and eruby-rails.snippets from the snipmate-snippets repository (owned by honza, but I don't have enough reputation to link to it here) (see the INSTALL section of the snipmate README for proper setup).
If you are using the maintained fork, I believe setting g:snipMate.scope_aliases in your .vimrc with the following will work for your example:
let g:snipMate = {}
let g:snipMate.scope_aliases = {}
let g:snipMate.scope_aliases['eruby'] = 'eruby,eruby-rails'
I've added a pull request to snipmate to have their documentation updated.
Jumping on the UltiSnips bandwagon after trying SnipMate for a while. Like SirVer mentioned, having the html, ruby, etc snippets available within an *.erb file was as simple as adding the extend line to the eruby.snippets file.
With the original snipMate plugin, create a file ~/.vim/ftplugin/erb_snippets.vim and put the following into it:
silent call ExtractSnipsFile(g:snippets_dir . 'html.snippets', &l:filetype)
silent call ExtractSnipsFile(g:snippets_dir . 'ruby.snippets', &l:filetype)