I need to get my Meteor JSapp in more than one language.
What would be the best approach for i18n?
Google passed my quite a bit of results but reading them I am more confused than happy. There a many hacks but is there a settled solution to this?
This is more a comment than an answer (however my repu still is too low :o):
Localization normally is only needed client side (there are exceptions but not many and they can be dealt with) and as Meteor is quite young with an own templating engine it's normal that you find more hacks than stable solutions.
However you can doge that bullet by using an older client side templating technique than Meteors built in one like AngularJS with Angular-Meteor (http://angularjs.meteor.com/). Personally I can just recommend this project as it gives you a lot more power than Blaze alone does. And now when you look for solutions for localizing AngularJS you will find a lot more. One I can recommend is angular-gettext (https://angular-gettext.rocketeer.be/) which also comes with a grunt script to extract and compile your strings in one click and which builts a .pot file so that you can translate your app with PoEdit just like you would with an old school webapplication. The only thing you may need to do yourself is to extend the grunt script to parse for any custom translation functions you may add (but maybe you can live without those than you wouldn't need to do anything).
Related
The HTML/JS .aspx pages in my ASP.NET application use the MicrosoftAjax.js file like :
<script src="../../Scripts/MicrosoftAjax.js"></script>
Considering MicrosoftAjax.js is very old, I want to replace the MicrosoftAjax.js file with TypeScript (.ts) file and serve the same purpose. I am a bit not clear how complex this change would be and its impact as I am not much familiar with Typescript.
Are there any specific steps that i can follow to do this change ?
Well, you can download the ajaxcontrol tool kit source code.
All of the JavaScript routines are included.
thus, you could thus try and modify the toolkit source code to use TypeScript.
but, unless you willing to modify that code, look at the code, and play with the source code?
Then why bother with TypeScript. I mean, you MUST be adopting TypeScript for a reason - like say NEW software development?
I mean, why do you care if the jQuery, or jquery.UI library that SO MANY use in their projects is TypeScript or not?
Answer:
You don't give one hoot - do you?
Unless you plan to active modify that JavaScript library, and make changes.
If you not planning to make changes to that code, then I see ZERO reasons to worry about that code being JavaScript, or some .net "layer" is tossed on top called TypeScript to (hopefully) make writing your JavaScript easier.
I mean, I am looking at TypeScript, since writing JavaScript tends to suck HUGE!!!
Here we are with the fantastic .net framework, classes, great and fantastic type checking, strong data typing, and then we have to jump down to writing JavaScript with all of its warts, and INCREDIABLE PAIN and suffering when writing js code. It is beyond pain - it just is.
Now, don't get me wrong - we all as developers have to mess with js code. And that js gives us the abilities to write really nice interactive and responsive web applications. So amazing are the results, that we now can actually provide, and write and build applications that give EVEN BETTER user experiences then even what desktop software offers (at least in most cases - business applications). So I LOVE what client side JavaScript code can do for us - but this huge mess of JavaScript libraries - ever growing? It is killing the browser performance right now - and increasing load times - it is a mess our industry has to deal with. (and Blazer looks to be that solution).
So, I have now
AjaxToolKit - tons of JavaScript library routines
jQuery - a ton more of JavaScript library routines
jQuery.UI - a ton more of JavaScript library routines
jQuery.toast - a ton more of JavaScript library routines.
bootstrap.js - a ton more of JavaScript library routines
And so on!!!! (probably left out a dozen more!!!!).
I mean, REALLY when is this madness going to stop!!!
Exactly how many external js libraries do you expect me to have to adopt?
But, NOTE VERY careful - library routines!!!!
That means this is code I don't maintain and modify and care about.
(so who cares if that external library code is Typescript or not???)
There is NOTTHING stopping you from using TypeScript for YOUR code, but who gives one hoot about all the above external library code routines - why not just use them?
In fact, this is quite much why I can't wait to get up to speed with blazer. Blazer might be REALLY cool because I can now run my .net code client side. (how cool is that!!!) - no more JavaScript code!!!! Our savior has arrived!!!
But, what is MORE valuable in Blazor is not that you can write .net code (c# right now - hopefully they will add vb.net some day - but it don't look like that will occur).
The HUGE value is I can now dump that train wreak of having to adopt a gazillion external script libraries, and now use ONE seamless language for both server side code, and client side code. No more JavaScript, but MORE important I can then adopt pure nice clean .net code - and that code will be for both ends. And that means things like say moving a class object from server side to client side - and I don't have to muck around with JSON, or serialization , or anything - it all the same code, and thus moving data types from server to client side becomes not only near automatic, but seamless, and the same language. and it runs at compiled speed browser (client) side. Blazor has the potential to get rid of ALL THAT nonsense, including that of killing the browser side with a NEVER ending and EVER growing list of external JavaScript libraries to just build a decent working web page.
It is the galactic mess of all these libraries, and killing the browser with that truckload huge payload of external libraries that is the big mess right now.
Blazor has the potential to just toss ALL OF THAT hair ball mess out the window.
Now WHY do I mention the above? Well, if you going to consider modifying the ajax tool kit source? I would consider a migration to Blazor - and not TypeScript.
But, then again, we STILL not answered why you care?
I see ZERO advantage to change the jQuery libary code, or in this case the ajax control tool kit to using typecript UNLESS you going to actively modify the source of that external libary in the first place.
I mean, why do you give one fying hoot that jQuery, or jQuery.UI is JavaScript, or some layer on top called TypeScript is being used? (perahps bettr inteli-sense???).
So, the tool kit is open source.
I did in fact modify the ajax file up-loader.
I needed two things:
First, I wanted the time remain for a up-load (who left out that feature!!!!).
But then again, that is the beauty of the ajax tool kit - it is open source. So, now my up-loader shows the time remain like this:
And the other missing feature? Well, the 3 events for the ajaxfile up-load. I wanted to be able to pass values from the up-loader to the server side events. So, I modified the events, and now I can pass a jason string - that effective allows me to pass a "class" up during the up-load process.
Now, could have I decided to spend all that extra time to make this code work as TypeScript? Gee, that would be quite a bit of messing around and extra time.
But, the fact that I already use all those external libraries (jQuery, jQuery.UI and a bunch more? I don't see the need or goal here.
We all use truckloads of those externa js libraries. Unless we plan to active MODIFY such code, then TypeScript gives ZERO value to me as a developer.
And adopting TypeScript in YOUR code does not prevent you from using and consuming that boat-load of externa js library code that you FOR SURE are using these days.
So, to answer your question?
If you want to download a copy of the ajaxtool kit, and add type script tags, and re-compile the whole tool kit on your own - and with Type Sciprt?
Sure, go ahead, but I fail to see the goal here unless you actually willing to download the source and you plan to active modify and mess around with the source code.
If you JUST going to continue to use all those external library code, then I see zero advantages to bothering with TypeScript in those external libraries - just use TypeScript FOR YOUR code development - not everyone's else JavaScript library code that you now using anyway.
I mean, do you care that jQuery, or bootstrap.js is TypeScript? Don't' think so.
But hey, the ajax tool kit is open source. You can jump right in to modify that library code, but I don't see any benefits to doing so.
I am styling a project built on Meteor and using LESS. I use Brackets for styling because its Live Preview feature makes working with CSS a lot quicker and more pleasurable, but by Meteor's nature it doesn't seem possible to use this feature.
Every little change I make on the code has to be detected by Meteor, who will in turn refresh the project on the browser for me, and this process is now taking anything between 5 and 10 seconds, which is entirely too much.
Does anyone know if it's possible to work on "live" CSS/LESS, using Brackets, in a Meteor project, without having to wait for Meteor to notice my changes and take its sweet time to refresh the whole thing for me?
Or at the very least least if there's anything I can do to shorten the time Meteor takes to update?
I don't think it is possible unless the developers of Brackets go an extra mile and implement a specific support tailored for Meteor.
Brackets works on top of raw CSS and HTML files and uses Chrome Dev Tools API to manipulate the page.
Meteor doesn't send raw files to the client. HTML templates in Meteor get compiled to JS DSL and CSS is concatenated and sent in a manipulated form, too.
Bracket's live preview feature would work only with quick page layout prototyping and will not play well with any modern front-end tool chain that involves compiling pages and stylesheets or preprocessing.
Looking for a simple html templating solution for small sites.
I really want to do some basic includes (similar to some super simple PHP) that generate out to flat html. I had tried using Assemble.io but it seems to contain so much more.
For reference I'm coming from mixture.io which has some really easy templating but since it is a subscription I cant have that be the way our whole office makes sites. I have also seen middleman but I feel like node is just a lot easier to deal with.
I feel like there is a way to do what I'm looking for with mustache alone but my javascript is not very good. Any help would be greatly appreciated.
I'd recommend looking into Cabin
http://colinwren.github.io/Cabin/
Workflow uses Grunt and they added livereload support in the last release. Good alternative to using Jekyll.
Did anyone has the comparison between these two libraries (Combres2 and SquishIt)? If one library is better than another one, I also want to know the reason for that.
I found the article said that Combres2 has a better compression than SquishIt. But it is almost a year ago.
http://blog.buzzuti.com/post/Combres-vs-SquishIt-e28093-A-battle-of-Minification-Combiner-and-Squishing-in-generale280a6.aspx
One thing to make note of is that SquishIt works in a different manner than Combres2, so it isn't a simple who produces better minified code.
SquishIt works very nicely with T4MVC, which you won't get with Combres2. On this basis alone I'd tell anyone to use SquishIt. Additionally, SquishIt is not xml config file based, which allows for a lot of flexibility. In fact, you could theoretically make an xml config file and mimic Combres2 if you really desired it.
In terms of minification SquishIt is actively developed, which means that if new methods to minify scripts are created you'll be more likely able to leverage that as well. Currently it supports JSMin, YUI, MS Ajax Minifier, Closure Minifier, or even no minifier.
Update 1/18/2012: There are now many other alternatives out there aside from SquishIt and Combres2. For starters, Microsoft is creating there own system for the next release of ASP.NET 4.5. Cassette, similar to SquishIt, and RequestReduce, which is quite different than anything else by automagically doing everything for you.
I'm a fan of SquishIt.. even though Combres and SquishIt both (optionally) use the YuiCompressor.NET library (which I am biased, for ;-) )
Being a fan of Justin Etheredge, I recommend/use SquishIt.
The reasons to one library is better than the other (for me) is if the final result is NOT a break code and still working.
I have test and working with the Microsoft Ajax Minifier, and I assure you that is working absolute correct - can even minifie the jQuery library with out any issue.
http://ajaxmin.codeplex.com/
http://aspnet.codeplex.com/releases/view/40584
documentaion:
http://www.asp.net/ajaxlibrary/AjaxMinDocumentation.ashx
Now if a library is one year old this have nothing to do, because they just working on javascript code that have some standards some years now.
To point again out : the better is the one that product minimum code that is still working under very complex javascript functions like the one jQuery have.
One note:a minified library can minified a full set of files at ones, do not try to minified one by one and them add them to a single file, this is not working.
This is meant as an answer to the 'Microsoft Ajax Minifier' recommendation, and a general warning for those that do so. As my reputation is a mere 41, I cannot add the comment there, where it should go. :(
For our team, the native C# VS2017 Microsoft compression (which may or may not be the same as the one labeled as 'Microsoft Ajax Minifier') failed on the css function 'calc', and badly.
That was a bit tricky to track down, since the error (obviously) only occurs during minification. And since we were minifying based on environment (interwoven with Release, Debug), that meant the calc bug (by default) never appeared on local. It just magically appeared when we pushed to production... and only on pages that used the calc function.
(Definitely agree that minimum code add-on is fantastic. But the native minifier can be faulty. So proceed with caution.)
If you are not using 'calc' (and you are noticing no other issues), then likely your team is fine with the default minification tool.
And of course, Microsoft could have fixed the bug since we discovered it. But bug reporting through msdn doesn't always lead to resolution of the issue. :(
There may be other issues. But in our case (since we use 'calc'), that was sufficient to have us investigate other minifiers, and SquishIt has been our team's choice. We had not looked at Compres2 at that time. Up until now, we've been very happy with SquishIt.
Side note: I'm in the middle of investigating minifiers again because of some sort of 'collision' between jQuery 3.6.0 and SquishIt for VS2017. (with no 'collision' between jQuery 3.4.1 and SquishIt, VS2017). Early stages of problem-solving process.
Best wishes and happy coding,
Michael M.
I'm looking to see if anyone has any resources or tips for developing basic Drupal modules faster? Have you come up with anything to make your Module development faster?
The Drupal module documentation is kinda hard to understand and pretty massive. I'm wondering if anyone has simplified it and given techniques/tips for getting specific things done quickly. I'm currently looking for Drupal 6 and 7. Any help saving time will be greatly appreciated :-)
In general, I'd recommend picking up a copy of the Productive Programmer. There's nothing earth shattering in it, but there are lots of small tips that can increase your productivity incrementally.
For Drupal specifically, Pro Drupal Development and Pro Drupal 7 Development, though not focused strictly on speed of development, are indispensable.
Beyond that...
in the first place, if you don't have to, Don't Write Code
get familiar with the most commonly used hooks
learn to use Drush and Drush Make
learn to use Devel and Theme Developer modules
use the Schema module to generate your module's schema code, based on an existing table
use the Data module (+ this patch) to generate the code to expose your module's tables to Views
use the Form Builder module to generate form code
use Coder to learn the Drupal coding standards, which will help others help you
set up "quick searches" to allow you to quickly search api.drupal.org
learn the shortcuts in your IDE or text editor (I like Netbeans partially because of the Drupal plugin); print out a good cheatsheet
learn to use version control effectively
Well, there really no fast track to it. If you understand the Drupal API regarding module development (install, menus, blocks, forms, etc) you will grasp it. The hardest part I remember was wrapping my head around the menu system.
One thing that helped was taking simple modules and seeing how they worked, and problem solving my own solutions. Reading Pro Drupal Development helps too.
You basically need to have an understanding where to look (API function, hook, system... ) when you want to do X. There is really no need to memorize all hooks/functions in detail with all the arguments and stuff. That's something you can easily look up. Especially if you're using an IDE with I suggest (Using Netbeans myself).
Especially when you're altering stuff, try to develop some techniques to quickly figure out what code is responsible for the stuff you want to change. One example is to look at the hook_menu() definition of the module that does it and then check out the page callback and skim through the code. Things to look up: Are there hooks you can use, is it a form (if yes, what is the form_id, how is the form structured) and so on.
The best and maybe only way to get there (knowing where too look) is exercise. Every time you do something, you'll be faster the next time when you have to do something similar. I think what also helps is working on core/contrib modules together with others. You not only get to learn these modules better, you also learn how to read and understand code written by others better and you improve your own coding style.
Try to utilize proven, generic "building block" modules like Views, Flags, Panels, CCK/Field and so on. Then, the heavy lifting is done by these modules and you only need to provide the glue code to properly integrate them with your site. Might take a bit more time the first time you use these modules but you will likely save a lot time after that.
That having said, I'm not sure if the goal should be to build modules fast. I'd say the goal is to build modules better. Try to make them generic, secure, flexible, theme-able and so on with the goal to re-use these modules on the next site your building, when you need something similar.
The majority of basic drupal module development is copy and paste. If you use textmate, the Drupal bundle for it allows you to build up key bits of modules (menus, theming functions etc) just by point and click (as it contains most of the necessary code snippets; you just fill in your info).
Following the module building tutorials is good too; the truth is, if you spent 3 or 4 weeks doing it day in day out, and you already have some background in coding, you'll be just fine.
Gedit for Drupal will preconfigure the very good Gedit editor/IDE for you.
For example, a new module: create an empty module file mymodule.example. Enter that file.
module<tab> And it expands into a full, predefined module.
Or in any module: hook<tab> to see a list of available hooks. Choose e.g. menu<tab> and it expands to a full predefined hook_menu. With <tab> you can walk trough all the variable parts in that new hook, to fill in the details.
Drupal.rb Has a.o. a $ drupal generate module "modulename" command that opens an interactive shell, wich allows building scaffolds for modules. The templates from which these scaffolds are built, are overridable.