I'd like to use the PlantUML syntax to define component structures, which I want to process in an own tool. However, I'd like to avoid having to write a PlantUML parser. Is there some sort of intermediate representation in PlantUML, which I could use for that? It would be perfect to have e.g. a JSON structure which contains all diagram objects and relations among them in a concise way.
I could not find anything in the docs, maybe someone with more insights in the project can help?
As Jean-Marc Volle pointed out, the project github.com/jupe/puml2code allows to process puml files and generate source code in different languages using handlebar templates. Currently the code generation is limited to classes in a puml file.
I have used puml2code as a starting point for a new project github.com/robbito/puml2json, which simplifies the process a bit, as it doesn't require handlebar. Json ist directly generated from the PlantUML code. puml2json currenlty also only supports a subset of PlantUML.
Hopefully this isn't too broad of a question for here, but I am an amateur programmer who doesn't have much experience with super complex programming as of yet (I've mostly used C for basic microcontroller and interface stuff so far).
I've noticed that a lot of applications have odd filetypes to store text data that seem to be different for the sake of it. For example, Valve video games store user settings in 'config' files that can be easily edited by any text editor. Is there a specific reason for this?
In other words, assuming the data doesn't need to be encrypted or secure in some way, why not store plain old text data in a plain old text file? What are common purposes of storing plain data in odd file types?
I want to store some custom information (tags) in a mp3 file (or even better, in any audio file, but mp3 would be a start).
What would be a good way to do that?
ID3? If yes, in what ID3-Section should that be (it shouldn't be overwritten by other programs). I thought of the "comment" section, but it is overwritten quite frequently, I think.
Is there an easy way to store information to any audio file?
UPDATE:
I decided to store the information into a custom ID3 Tag (with my own name) via the MyID3 library :)
It depends: If you want to use this custom information only for your own collection, you can store it to whatever tag you like. If you hope that your custom information can be read by (nearly) all popular music management tools, I suggest that you store it to the defined tags according the ID3v2.3 standard.
If your custom information doesn't fit into one of this tags, lets assume an example like: "eye color of the lead singer", you could make your own private tag. This is noted in 4.28 private frame with the description:
This frame is used to contain information from a software producer that its program uses and does not fit into the other frames.
I would like to make a program (I would prefer in C language) , but even in cocoa , that can take data from an external program (such as iTunes or adium) and will use them. For example i would like to take the data of a listbox or the text of the chat so as to manipulate it. I need a place to start. In windows I think it is possible with some apis that find the hWnd of a window and then find a pointer to the listbox or textbox. Please give me some info on how to start. Thanks you in advance.
It's not clear exactly what you want to do. It's either impossible or severely restricted.
For one thing, different applications use different ways of constructing a “listbox”—Cocoa applications use NSTableView, Carbon applications use DataBrowser, and GTK, Qt, and Java applications use even more different APIs. These do not all go through some common kind of list box thingy; each is an independent implementation.
(You could hope that either NSTableView or DataBrowser would be based on the other, but don't count on it.)
For another, it is impossible to obtain a pointer to that control. You cannot access another application's NSTableView or DataBrowser view or GTK/Qt/Java equivalent unless (and this only works for NSTableView) that application deliberately serves it up to you. It doesn't sound like that's your situation.
The closest you can get to that is Accessibility, which may be pretty close, but is unlikely to work with most applications not based on Cocoa.
Even then, the view may not be showing you all the data. A table view may be lazily populated, and a table view designed in imitation of the iOS UITableView may even never have all the data (because it only has what it can show).
(All of the above applies to every kind of view, not just table views. Collection views, text fields, buttons—same deal for all of them.)
The only way to get at the true, complete copy of the data is to ask the controller that owns it. And, again, that's impossible if the application is not specifically offering it to you. Not to mention, the application might not even have a controller (not object-oriented, not MVC, or just sloppily made).
… so as to manipulate it.
Getting the data in the first place is the easy part. It is nigh-impossible to mess with data in another application—for good reason.
The closest you're going to get to either of these goals is the Accessibility interfaces.
So we are sure that we will be taking our product internationally and will eventually need to internationalize it. How much internationalizing would you recommend we do as we go along?
I guess in other words, is there any internationalization that is easy now but can be much worse if we let the code base mature and that won't slow us down very much if we choose to start doing it now?
Tech used: C#, WPF, WinForms
Prepare it now, before you write all the strings in the codebase itself.
Everything after now will be too late. It's now or never!
It's true that it is a bit of extra effort to prepare well now, but not doing it will end up being a lot more expensive.
If you won't follow all the guidelines in the links below, at least heed points 1,2 and 7 of the summary which are very cheap to do now and which cause the most pain afterwards in my experience.
Check these guidelines and see for yourself why it's better to start now and get everything prepared.
Developing world ready applications
Best practices for developing world ready applications
Little extract:
Move all localizable resources to separate resource-only DLLs. Localizable resources include user interface elements such as strings, error messages, dialog boxes, menus, and embedded object resources. (Moving the resources to a DLL afterwards will be a pain)
Do not hardcode strings or user interface resources. (If you don't prepare, you know you will hardcode strings)
Do not put nonlocalizable resources into the resource-only DLLs. This causes confusion for translators.
Do not use composite strings that are built at run time from concatenated phrases. Composite strings are difficult to localize because they often assume an English grammatical order that does not apply to all languages. (After the interface design, changing phrases gets harder)
Avoid ambiguous constructs such as "Empty Folder" where the strings can be translated differently depending on the grammatical roles of the strings' components. For example, "empty" can be either a verb or an adjective, and this can lead to different translations in languages such as Italian or French. (Same issue)
Avoid using images and icons that contain text in your application. They are expensive to localize. (Use text rendered over the image)
Allow plenty of room for the length of strings to expand in the user interface. In some languages, phrases can require 50-75 percent more space. (Same issue, if you don't plan for it now, redesign is more expensive)
Use the System.Resources.ResourceManager class to retrieve resources based on culture.
Use Microsoft Visual Studio .NET to create Windows Forms dialog boxes, so they can be localized using the Windows Forms Resource Editor (Winres.exe). Do not code Windows Forms dialog boxes by hand.
IMHO, to claim something is going to happens "in a few years" literally translates to "we hope one day" which really means "never". Although I would still skim over various tutorials to make sure you don't make any horrendous mistakes. Doing correct internationalization support now will mean less work in the future, and once you get use to it, it won't have any real affect on today's productivity. But if you can measure the goal in years, maybe it's not worth doing at all right now.
I have worked on two projects that did internationalization: a C# ASP.NET (existed before I joined the project) app and a PHP app (homebrewed my own method using a free Internationalization control and my own management app).
You should store all the text (labels, button text, etc etc) as data inside a database. Reference these with keys (I prefer to use the first 4 words, made uppercase, spaces converted to underscores and non alpha-numerics stripped out) and when you have a duplicate, append a number to the end. The benefit of this key method is the programmer has a pretty strong understanding of the content of the text just by looking at the key.
Write a utility to extract the data and build .NET resource files that you add into your project for compile. Create a separate resource file for each language. In your code, use the key to point to the proper entry.
I would skim over the MS documents on the subject:
http://www.microsoft.com/globaldev/getwr/dotneti18n.mspx
Some basic things to avoid:
never ever ever use translation software, hire a pro or an intern taking that language at a local college
never try to create text by appending two existing entries, because grammar differs greately in each language, this will never work. So if you have a string that says "Click" and want one that says "Click Now", do not try to create a setup that merges two entries, or during translation, copy the word for click and translate the word now. Treat every string as a totally new translation from scratch
I will add to store and manipulate string data as Unicode (NVARCHAR in MS SQL).
Some questions to think about…
How match can you afford to delay the shipment of the English version of your application to save a bit of cost internationalize later?
Will you still be trading if you don’t get the cash flow from shipping the English version quickly?
How will you get the UI right, if you don’t get feedback quickly from some customers about it?
How often will you rewrite the UI before you have to internationalize it?
Do you English customers wish to be able to customize strings in the UI, e.g. not everyone calls a “shipping note” the same think.
As a large part of the pain of internationalize is making sure you don’t break the English version, is automated system testing of the UI a better investment?
The only thing I think I will always do is: “Do not use composite strings that are built at run time from concatenated phrases” and if you do so, don’t spread the code that builds up the a single string over lots of methods.
Having your UI automatically resize (and layout) to cope with length of labels etc will save you lots of time over the years if you can do it cheaply. There a lots of 3rd party control sets for Windows Forms that lets you label text boxes etc without having to put the labels on as separate controls.
I just starting to internationalize a WinForms application, we hope to mostly be able to use the “name” of each control as the lookup key, without having to move lots into resource files etc. It is not always as hard as you think at first….
You could use NGettext.Wpf (it can be installed from NuGet, and yes I am the author, but I made it out of the frustrations listed in the other answers).
It is hosted this github repository, and here is the getting started section at the time of writing:
NGettext.Wpf is intended to work with dependency injection. You need to call the following at the entry point of your application:
NGettext.Wpf.CompositionRoot.Compose("ExampleDomainName");
The "ExampleDomainName" string is the domain name. This means that when the current culture is set to "da-DK" translations will be loaded from "Locale\da-DK\LC_MESSAGES\ExampleDomainName.mo" relative to where your WPF app is running (You must include the .mo files in your application and make sure they are copied to the output directory).
Now you can do something like this in XAML:
<Button CommandParameter="en-US"
Command="{StaticResource ChangeCultureCommand}"
Content="{wpf:Gettext English}" />
Which demonstrates two features of this library. The most important is the Gettext markup extension which will make sure the Content is set to the translation of "English" with respect to the current culture, and update it when the current culture is changed. The other feature it demonstrates is the ChangeCultureCommand which changes the current culture to the given culture, in this case "en-US".
I also highly recommend reading Preparing Strings from the gettext utilities manual.
Internationalization will let your product be usable in other countries, it's easy and should be done from the start (this way English speaking people all over the world can use your software), those 3 rules will get you most of the way there:
Support international characters - use only Unicode data types in files and databases.
Support international date, time and number formats - use CultureInfo.InvariantCulture when storing data to file or computer readable storage, use CultureInfo.CurrentCulture when displaying data or parsing user input, never do your own parsing, never use any other culture objects.
textual data entered by the user should be considered a black box, don't try to break it up into words or letters, especially when displaying it to the user - different languages have diffract rules and the OS knows how to display left-to-right text, you don't.
Localization is translating the software into different languages, this is difficult and expensive, a good start is to never hard code strings and never build sentences out of smaller strings.
If you use test data, use non-English (e.g.: Russian, Polish, Norwegian etc) strings.
Encoding peeks it's little ugly head at every corner. If not in your own libraries, then in external ones.
I personally favor Russian because although I don't speak a word Russian (despite my name's origin) it has foreign chars in it and it takes way more space then English and therefor tests your spacing too.
Don't know if that is something language specific, or just because our Russian translator likes verbose strings.