On Mon, 18 May 2009, Szak�ts Viktor wrote: Hi,
> The problem is we already use .hbl for compiled language files, so > I cannot make above change. > These are my questions: > - Is there any better idea how to cleanup these file extensions? > - The standard extension for compiled .po language files is .mo. > Would it be possible to switch to that? This could also mean > to change binary format to be .mo compatible. I can't really > oversee the performance and development consequences of > that, but it *might* be nice to use an already existing file format. > This could open usage of already existing external tools which > can handle .mo files natively. > [ I like current .hbl format very much BTW, so no offence on > current format. ] .mo are gettext compatible compiled .po files. I plan to add support for native gettext usage and in such case it will use .mo files by gettext API resepcting domain names and .mo file localization (it's strictly defined), etc. I think it will be important extension for people who want to create well integrated with *nix systems applications, f.e. some additional system tools. Anyhow I do not think that non *nix users will use it. gettext is hard to use with stand alone Windows or DOS applications. We can also try to use .mo files as holder for our compiled .po modules (now stored in .hbl files) but it will cause the some problems: 1. we have extensions which are not gettext compatible and probably we will have to drop them. In some cases it will be serious functionality reduction. We will lost plural form support for non EN languages used as based language. Evan more, the base language should be EN what creates problem for people who want to use i18n API with their existing application which do not use English as base language. It will be necessary to respect strict enocding rules used by gettext, etc. 2. we are using compiled binary format to speed-up load operation. If we use .mo files then we will have to read data and then decode it to the format acceptable by our HVM (of course if we do not want to replicate the rest of gettext runtime logic in our code). It means that we will not have performance improvement by using binary format. In such case it's possible that it will be more efficient to rewrite in C function to decode .po files and use them directly instead of .mo files. 3. .mo files have strictly defined localization which is OS dependent. Distributing our own .mo files with our own localization rules adopted to easy use in other OS-es can create serious troubles if real gettext applications are also used or when we add native gettext support. In summary. I'll add support for .mo files as alternative i18n module which will use internally gettext library respecting all gettext rules. In some cases users may find it as important extension and use it instead of our own i18n formats but I do not think that it's good idea to hack .mo files and use them as holder for translations without strict respecting all gettext rules but with our own ones which will make them usable in non *nix environments. > [ BTW2: hbi18n won't allow .po extension in -m operation, it > will automatically change it to .pot. AFAIK it respects any extensions when -o <filename> is used and does not add any new one or overwrite existing if <filename> already has extension. It only forces .pot extension when there is no -o option. I planed to ask about default extension for merged .pot files (.pot or .po) preferred by Harbour developers/users and I even marked it in the hb18n help info as .po_ but I simply forgot about it. As I can see the ".po_" is still in the usage screen so we should decide about it. > These are the official gettext extensions: > - .pot - extracted strings from a source file (template) > - .po - extracted strings + translations - text format > - .mo - extracted strings + translations - binary format ] yes, it is. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
