Is there any free dictionary I can use for i18n?
Free as in open source / creative commons, ideally also for use in a commercial product.
Looking at the KDE i18n projects, they have translated a lot of applications in many languages. Is there a way I can use their dictionaries for a standard Qt (non-KDE) application - and am I allowed to?
You should contact the KDE localization team if you have questions about licensing of their translations.
I don't think that the l10n support of KDE applications will help yoiu directly -- they ship as a catalogue of strings, as appears in a particular context in the original application, and the translated form. There is a long way from that to automatically using the data in the context of another application, and that's also the reason why machine-generated translations have such a low quality. If you cannot speak a language and don't have anyone who could do the work for you, you won't be able to ship a working localized version in that language.
Related
Is there an api within the POSIX UNIX API standard for access to clipboard, like fetching current pasted item, changing current pasted item etc?
Also what I see is there does not seem to be any community or atleast that I can find where I might find more resources and posts about people developing stuff using the POSIX APIs (I know its such a niche and probably there aren't many developers working on them everyday to churn out OSes like mcdonalds burgers). Could someone point me to an appropriate place if they know exists?
What's a "clipboard"? Isn't it a concept specific to GUIs? POSIX doesn't do GUIs.
For the POSIX API, go to The Open Group Base Specifications, volume System Interfaces.
POSIX describes the interfaces which the operating system exposes to application programs. It is a tool for application developers, not for operating system developers.
We are building an m-learning solution[IOS and Android compatible] at our company. The product needs to be SCORM compliant. I would like to know whether it should be developed in-house by the developers or other paid options should be pursued? What are other ways of making our product SCORM compliant? We are not rally positive about using SCORM Engine for this due to its high cost solution to our problem here.Any suggestion/help is appreciated.
You can include SCORM within content using a number of open source options available on GitHub.
Getting SCORM in the content (free) is step 1.
Packaging, bundling and deploying is really step 2.
This typically has a close relationship to how Curriculum defines a structure of lessons, modules, units etc. Not knowing exactly how they want to organize this, I can speculate that you may just have a simple "I want to know that the student viewed the content" approach. If you get into a more rich dependency on how the student performs dictating what they see or do next, that requires a much for up front design so you can bridge the design, development, and deployment of your content.
Including SCORM Support in content -
Like mentioned if you search google for my SCOBot project or Pipwerks you'll hit the ground running.
Requires JavaScript friendly developer and some base SCORM knowledge attained thru reading. This could be outsourced.
Knowing the version of SCORM you wish to support can help. Consult the LMS to find out that info.
Far as presenting / creating content; if you are doing this from scratch you'd need a HTML/JS developer or if its more interactive your dipping into WebGL, Canvas or beyond. There are other paid services like iSpring, Captivate and others that offer content creation with SCORM Standards support. They may even take care of the packaging for you (covered below).
Packaging -
This requires a zip (CAM content aggregated model) which includes a imsmanifest.xml file to describe a one to many relationship of a TOC. Again simple is 1, many begins to allow you to group tiers and add objectives and other things increasing complexity but doable.
You can perform creating this package with XML, Zip and specification knowledge. I have a Packaging app on my site and a Mac (free) applescript which can also perform very basic packaging. I am not away of any other free options.
Deployment
Commonly performed thru FTP/FileShare by uploading these CAM (zip) packages. LMS decompresses and reads the manifest. Sometimes you can just copy the raw files up to the LMS thru a media / content server but this greatly depends on the options.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I'm developing an application with the Qt open source edition. As I don't want to deliver the Microsoft Visual Visual C(++) redistributables, I'd like to use a static-linked version of Qt.
The Qt licensing information says that I "should" develop with a commercial Qt license if I want to use static linking in my application, although when I use the configure -static command for building a static Qt library the command prompt asks me if I use the commercial or open source version of Qt.
So it is possible to build Qt with the open source version? Do I need the commercial edition to use static linking? I won't sell the application.
EDIT April 2016
Actually, I have recently been reading in depth about LGPL, and asking some experts on the subject. Turns out that the inability to use static linking for Qt in closed source applications is more of a cultivated legend and has nothing to do with reality.
What LGPL requires is the possibility for the end user to relink the application against a different version of the library. Using dynamic linking is one way to achieve that, but you can just as easily provide your object files, this way you don't have to open your source and the LGPL requirement is still satisfied.
On the Qt website there are 2 legal FAQs and in neither of them is it directly stated that you can't do it. Just as it is not stated that you can. However, there are at least several instances of implying a vague legal threat in case that you do. I think there is a good explanation for all of those - they can't say that you can't do it without publishing a practical lie which may as well have negative legal repercussions for them, and they are willing to discourage doing that rather than encourage it, as it has the potential to force more people into purchasing a commercial license.
So in short, yes you can, and you most definitely should as lately Qt has become a living deployment hell, plus as of Qt 5.7 in a static build, QML files are tucked neatly in the executable rather than being out on the file system, for anyone to tamper with. Just make sure that:
your Qt build only contains modules, licensed under LGPL, and nothing GPL
the about section of your app mentions that it is using Qt and contains a link to where you can download the application's object files
include all the respective license files with your application
Lastly, your application actually has to be "relinkable", that is, it must be able to work with a compatible library version that provides the necessary functionality. Which means that if you have made modifications to Qt before building it, you must provide those in the form of source code as well, but only the modifications to Qt, not your application's source code.
Update:
Here is an excerpt directly from the GNU FAQ:
For the purpose of complying with the LGPL (any extant version: v2,
v2.1 or v3):
(1) If you statically link against an LGPL'd library, you must also provide your application in an object (not necessarily source)
format, so that a user has the opportunity to modify the library and
relink the application.
That states it pretty clear.
The old, original answer:
It is possible to build Qt statically as long as your application is open-source and you provide the source. If you want to keep your source closed, you either need an expensive commercial license, or you need to use dynamic linking.
BTW using a static build of Qt is pretty nice, for Qt5 I get about 7-8 MB executable with no external dependencies, which is much better than the 20+ MB of additional dll's you have to ship with a dynamically linked app.
For more information, you can take a look at this video: Making the correct license choice when developing with Qt
All in all, can it be done? 100% yes. Should it be done? It depends, for personal/testing/learning purposes it is 100% OK, however if you plan to distribute production grade software, be that commercially or not, open source or not, you'd better first consult with a lawyer. The whole subject is unnecessarily complicated, subject to interpretation, so that the consultation with a lawyer becomes more expensive than a pricey commercial license.
The answer is Yes, if you are willing to open source your application.
According to the Qt-Project's own interpretation of the licenses they use, if you dynamically link to the Qt libraries your application can be either closed source or open. If you statically link, however, your application is subject to the terms of the LGPL.
The exact language the Qt Project uses is this:
In case of dynamic linking, it is possible, but not mandatory, to keep
application source code proprietary as long as it is “work that uses
the library” - typically achieved via dynamic linking of the library.
In case of static linking of the library, the application itself may
no longer be “work that uses the library” and thus become subject to
LGPL. It is recommended to either link dynamically, or provide the
application source code to the user under LGPL.
(http://qt-project.org/legal.html)
The suggestion in some of the other answers that the situation is "not at all clear" is simply untrue - The Qt Project has tried to be abundantly clear about in what circumstances usage of the LGPL license is permissible, and static linking is one of those as long as the app is also LGPL.
Since the original question specifies non-commercial (not necessarily open source), the asker will need to decide whether they can allow distribution under the LGPL (or GPL by extension, as the above page also says "LGPL can be converted to GNU General Public License").
I work in a shop that is mostly .NET based, and we're trying to pick out a content management system to use. This means we mostly likely won't be able to use any of the common open source CMS projects (Plone, phpNuke, anthing not based on .NET, etc.).
Since I'm a huge usability nerd (just finished reading The Design of Everyday Things by Norman), I've been looking at them from that point of view. Frankly, I haven't been too impressed. This quote sums it up:
Most open source content management software is useless. The only thing worse is every commercial CMS I’ve used. - Jeffrey Veen
Here's a short list of our requirements:
Has to be .NET based
Prefer open source or on the inexpensive side
Limited feature set (we don't need too many features and they make things harder to use)
Does need Active Directory integration and robust permissions
Should be focused on web standards and usability
I know it's probably an impossible feature list, but are there any content management systems that kinda sorta look like they might not suck more than a Dyson?
Edit:
Here's the current situation:
I'm going to push for N2. I've got Active Directory integration working well (I even wrote a custom role provider). The only thing missing is workflow functionality. Hopefully I can get something going with that since it's the last sticking point. The N2Contrib project might provide a starting point if I can figure it out.
I would still love to check out Stencil CMS if/when it gets off the ground.
One of my co-workers was trying to get Umbraco going but wasn't having much luck.
Thanks for the help!
Self-plug is lame, but what you're describing is pretty much exactly what I am getting ready to release for $79 a pop. If you're still looking in a few weeks, take a peek. If you'd like, shoot me an email (rex#stencilcms.com).
I've heard both positive and negative feedback about Umbraco. A lot of people like Graffiti, but it's more blog-oriented than a full-blown CMS.
Check out N2 (http://n2cms.com/). I think that it covers most, if not all, of your requirements (I don't think it has Active Directory capability at this time). We are using N2 and I have really enjoyed how flexible it has been.
My company just completed a review of several commercial .NET-based CMS/portal platforms and, while I can't reveal who was in them (thanks, NDAs!), I can tell you that IMO they all sucked very, very badly.
Good luck on your search. I'll keep an eye on this thread in the hopes that there's something we missed.
We had a similar set of requirements and chose Telerik Sitefinity. It's got it's faults but overall I've been happy with it so far.
Unfortunately Jeffery speaks the truth. Which is probably why I build a new custom cms from the ground up every few years. Basically, the motivation for "boxed" CMS packages is to have every feature on earth and be everything to everyone and therefore do nothing particularly well for anyone. With the feature bloat comes the usability nightmares. Unless you start customizing and then you usually end up forking the project and losing the advantage of community updates.
Kentico CMS according your list:
Has to be .NET based
It's .net based, .NET Framework 2.0 or later
Prefer open source or on the inexpensive side
Free edition which can be used for commercial purposes is available, paid license starts at $750, source code is an option
Limited feature set (we don't need too many features and they make things harder to use)
Many built-in modules/features, anyway they can be easily disabled to keep the UI simple to use
Does need Active Directory integration and robust permissions
AD, Forms and Live Id! Integration
Should be focused on web standards and usability
UTF-8 Support including RTL languages, WAI Compliant, XHTML Compliant, XML, XHTML, HTML, XSLT, CSS.
Instant on-line demo or download available at:
http://www.kentico.com/Download.aspx
I want to serve a lot of big files in a Plone site. By big files I mean around 5MB (music) and a lot of them. I've already do it straight to the ZODB, not a good idea. I'm running Plone 3.1.1 and Zope 2.10.6.
Zodb blob support is the best, most integrated way to deal with large files. Big files are stored transparently on the filesytem instead of in the zodb object database. "Transparently" in this case means that you won't notice it in your actual programming work after initial configuration.
The blob functionality has been backported to current (halfway 2008) zope versions and can be used in plone 3. Use plone.app.blob in your project for this: http://plone.org/products/plone.app.blob.
Yeah, you shouldn't use anything else than the ZODB BLOB support at this point. It works fine with the 3.x series of releases.
More information in ticket #6805
— Alexander Limi, Plone co-founder
Clarifying, to the best of my knowledge:
from various candidate technologies in a PLIP (Plone Immprovement Proposal), plone.app.blob is the lead contender with widespread support
-- for exceptional use cases, we sometimes find something other than BLOBs recommended
4.0 is currently the most likely milestone for plone.app.blob to become a product within Plone core
in the meantime plone.app.blob is a recommended add-on product for current 3.x versions of Plone
-- for use cases that suggest BLOB-like technologies.
As you may already know, the long-term solution for this is supposed to be the ZODB BLOB support. Ticket 6805 is probably the most authorative source on this. Unfortunately, the milestone is set to 4.0, and running it in production on an older release is perhaps not a good solution.
There has, historically, existed a lot of Plone products for storing files externally, keeping only metadata in the ZODB. I have tried several of them, and from my experience, there is not a single one that works well with current Plone/Zope releases. Don't trust me on this, though, I have not tried any products of this type the last year or so.
Personally, I would go for a solution that is as simple as possible and doesn't involve Plone more than neccesary. Storing the music files on disk, serving them directly from apache/whatever web server you use, keeping only metadata in Plone - in a product you write yourself, will give you a robust solution with good performance. That is, your product should produce links to a path on your web server where the music files are available.
If you require authorization for download of the music files and assuming that you run lighthttpd or apache in front of your Zope, looking at a solution based on X-sendfile is probably the best option. With X-sendfile, you keep the files on disk, and add a header (X-sendfile) to the response when a music file should be sent to the client browser. The web server will pick this header up and send the file to the client, without Plone being involved.
Some pointers:
http://tn123.ath.cx/mod_xsendfile/ (The apache module)
http://john.guen.in/past/2007/4/17/send_files_faster_with_xsendfile/ (Ruby example)
I have plone.app.blob installed on some low-traffic sites and installable (ready to roll, if you like) for my busier production sites in the same instance.
There's the 4.0 milestone but I'll certainly review (and probably click the install button for plone.app.blob on my production sites) around 3.4 time.
A couple of references:
http://n2.nabble.com/PLIPs-I%27d-love-to-see-for-Plone-3.3-tp1123218p1130015.html
http://dev.plone.org/plone/ticket/8629#comment:2 highlight
… 3.4, when we'll probably have blob filestorage specification
support added to plone.recipe.zeoserver and zope2instance. That will
give us a standard location for whatever owner/permission fixups the
installers need to make.
In context: I'm playing roughly with plone.app.blob and a very mixed bag of other add-on products with versions 3.1.7 and 3.2a1 of Plone based on standard and experimental installers. In these environments, without me treating things with kid gloves, Plone sies behave remarkably well and when (as expected) experiments lead to oddities, the support from the community is paced and proper.