My windows forms application consists of one Visual Studio solution and several projects. The application is localized in English and French using resource files (each project has global resource files, e.g. fooResources.resx and fooResources.fr.resx, and each form/user control has its own resource files (e.g. fooForm.resx and fooForm.fr.resx) - so lets say for arguments sake I have about 30 sets of resource files.
I now have to extract all the strings to be sent for translation into German, then when I receive the translated strings create German resource files (e.g. fooResources.de.resx and fooForm.de.resx) which contain the new captions.
Obviously I could do all of this manually, but I am a developer and thus by nature lazy! No, just kidding - but I would appreciate some suggestions on the most painless way to do this as I am sure more languages will be coming in the future.
Thanks.
I'm the author of a translation product that makes the job very easy for both the developer and the translator. See http://www.hexadigm.com.
I've dealt with this a few different ways. I have worked with translators that are more than willing to work with .ResX files and will create the files as needed (though you may have to rename them to the proper locale code.
Otherwise, the contents of the resource files are purely XML. I wrote a little program that drops the xml data into a datagrid, and then imports the CSV or Excel file in using the key as a UID.
Related
I've done a bit of research, and it seems that the file type .rsc is used is many different applications. I haven't been able to find any sort of resource extractor or decompiler that can deal with .rsc files.
The objects of my interest: Sounds, images, and other various resources compiled as .rsc files for an old (1999) game made by The Learning Company. Since I have found ways to do this for many other games, I assume that there must be a way to extract and view the resources in their de-obfuscated form.
If nobody has ever figured this out yet, I'm willing to learn about how to write a decompiler and interpret the files. I of course, would need help with that too.
Ravioli Explorer's able to extract resources from that since all the other byond extraction tools aren't available. Try using it to open resources.
I am looking at how to implement PDF merging with raw VB code so that the code may be invoked by a bot for business process automation.
The software used to create the bot provides a function to invoke VB code, but I don't believe it can access any externally imported libraries because it expects plain source, so I essentially need to produce code that one could run in a VB shell environment without anything fancy (or convenient, it seems).
All the research I've done so far point me in the direction of external packages I would need to install, such as iText; this is what I'm looking to avoid.
(previous iText employee here)
PDF is not an easy (binary) format.
Essentially, blobs of information (text that has to be rendered, fonts, images, vector graphics, etc) are compressed and gathered into objects.
Each object gets a number. Objects are allowed to reference eachother (a piece of text might say 'I want to be rendered with font 4433')
All object numbers and their byte offset in the file are gathered in the crossreference (often called XREF) table.
A PDF includes a 'Pages' dictionary object that tells the viewer which objects belong on which page.
In order to merge PDF files, you would need to:
- read all XREF tables of all files
- adjust all of those to the correct byte offset
- update various dictionary objects within the PDF file that tell it where all the objects per page are kept
This is by no means a trivial task, but it can be done using only VB.
If you are serious about implementing a robust, scalable version of this of tool, perhaps it's better to look at the iText sourcecode and try to port it to VB?
Our current system database system is a clipper DOS application. The database inside its folder is fragmented/divided into many parts. I want to decrypt the database so that I will have only one database in all and avoid reshuffling of data. I'll attached the file folder Screenshot.. the database is on .DBF format
VScreenshot of files
Often you can decompile the CLIPPER exe file to source code and work from the .prg I've done it many times. The program to use is called WALKYRIE.
In Clipper and Fox Pro for DOS .dbf file is a simple table file.
If You want to use as data base with many tables in one unit.
You can import these tables in MS SQL data base and/or part of a MS Access database.
I see that you got several answers. Most are partially right. Let's address these one at a time:
All those files essentially comprise the "database" for the application you're using. They could be used by other applications as well. Besides having a lot of files, what is the problem you're trying to solve?
People mentioned indexes. You can generally ignore these. There are there primarily to make access to the data files faster. Any properly written clipper application will recreate these if they're missing or corrupted. You could test this by renaming one, running the app, and seeing what happens. If it doesn't recreate it you can name it back. Not replacing missing index files would be unusual behavior.
The DBF file format is binary, but barely. Most of what's in a DBF is text and is readable with an editor. But there's no reason to do so - I'm sure there are several free DBF utilities out there to to read DBF files. Getting the structure of the files could be very helpful.
Getting the data out of the files would also be fairly simple with a utility. If you look up the DBF format you could even write one fairly easily in Clipper, any other language that uses DBF files, or in something like Python. Any language that can open and write files, really. It's not hard - any competent developer could do this in a matter of hours. Must less if you're using Clipper or another language that natively reads DBX files.
Most people create dBase/Clipper programs with relational data, like SQL Server. Where SQL Server has tables that relate to each other dBase/Clipper has a file for each "table." This isn't a requirement, but it was almost certainly done this way.
Given that, if you get the table structures through a utility or by reading the headers in an editor (don't save them from an editor!) you could quite likely recreate the database schema (i.e. the map of the data). Once you have that it's fairly trivial to get the data into another type of database (SQL Sever, Access, or whatever you like to use.) If non of the files are too large it's conceivable to put all the files into Excel sheets. It really depends on what you want to do with it.
As others have said, you may be able to get the code by Valkyrie. Some people have used it very successfully. I don't know where you get it and I've never used it. Why do you not have the code? If this is a commercial application you likely should not have it. If it's a custom app who ever wrote it or paid to have it written should have the code.
Again, it's not clear to me what problem you're trying to solve. But there are many options for doing something with those DBF files. Fortunately they are one of the easier to read data formats you could be working with.
Let me know if you have any questions. Apologies for the typos that are no doubt scattered throughout this reply.
You sort of can get an idea of how they relate to each other by opening the index files they use (.NTX files). If you have the DBU utility (executable) around, you can open the DBF and load the index (NTX). LibreOffice Calc is also able to open DBFs (haven't tested .NTX).
If you open the .NTX on a text editor you will see the indexes in the beginning.
I open with Access, but I can save the data using a PrintFill Program.
Within a Silverlight library, I need to validate incoming XML against a schema. The schema is composed of 5 interdependent .xsd files; the main file uses "xs:import" to reference all of the others, and there are other references among them.
Assuming that the .xsd files need to be distributed with the library (i.e. not hosted on some well-known external URL), how should I structure my project to include them?
I have found that I can embed them in the library project with build type "Resource" and then load them (individually) using Application.GetResourceStream() and a relative URI with the ";content" flag in it. But if I take this approach, can I validate against the interdependent set of 5 files? What happens when the schema parser tries to resolve the interdependencies?
Or should I embed them with build type "Content" and access the main one with some other sort of URL?
Or???
To summarize: how should I use these 5 .xsd files in my project so that I will be able to validate XML against them?
EDIT: It's not clear whether it's even possible to validate in Silverlight. I spun off a related question.
I cannot say much about Silverlight limitations with respect to validation, but the question itself is more generic - one might want to store .xsd files as resources in a desktop .NET application, for example - so I will answer that part.
You can have full control over resolution of URIs in xs:import by means of XmlSchemaSet.XmlResolver property. Just create your own subclass of XmlResolver, override GetEntity() method, and implement it using GetResourceStream(), or GetManifestResourceStream(), or whichever other way you prefer.
I've been doing localization for my WPF application by storing strings in .resx files. My default (english) string resource is strings.resx. For other languages are called strings.fr-FR.resx for French, strings.es-ES.resx for Spanish and so on.
This method of localization has been great as my app will automatically load up the right string when I set the Globalization region to a matching locale, and defaults to English when there isn't.
Is it possible at runtime to enumerate which languages are in my Assembly?
I could get around this and hard code in which languages are included, but this can change from build to build as a build server is putting together the language resx's and building dynamically.
I see two options, none of which is ideal...
Enumerate all known cultures (CultureInfo.GetCultures), and try to get a given ressource for this culture => simple but slow
Look for satellite assemblies in your application's directory : for each subdirectory, check if it's name corresponds to a culture name (CultureInfo.GetCultureInfo), and if it contains a .resources.dll file