LCLTranslator have not really the same purpose. LCLTranslator need more work to be use as is and quickly
As I already wrote you don't need any translation unit at all for providing multi-language support for a package. Just
- declare all string constants as resourcestring
- activate i18n in the project options
- and define a folder for the po files created by the LCL.
You do exactly this in the gifviewer unit, and this is correct.
Things are different in an application, like your demo gifview. The application must know which version of the translated po files will have to be used, and it will have to switch between translations. For this purpose, translation support units are required. The key building blocks are contained in units such as "Translations" and "LCLtranslator", but I agree that there is a need for more ready-to-use routines.
I see two .po files in your locale folder. Translaters don't like this. Usually they prefer a single po file per package.
I don't know that. Lazarus generate automatically One PO file for One Unit. Where i can set this option ? and how to manage it for translation ?
Lazarus creates a po template for each unit which contains at least one resourcestring declaration. In otder to have a single po file for the translators, you just should pack all resource strings into a single unit and "use" this in the package and in the application. The single resource string unit will correspond to a single po file. Look at Lazarus' lclstrconsts: it contains all the strings used by some unit of the LCL - this is for the LCL package. The application, Lazarus, has another translation unit, lazaruside, which collects all the strings used by the Lazarus application somewhere.
I just want to share my work.
Great!
FPReadGIF not take in charge animation
Agreed, and this is a good reason for your work.
I think the FPC and LAzarus graphics solution be must be rethinking. Just see a little part in my code why i can't manage transparency correclty with TBitmap (just under linux) and must use TLazIntfImage instead ? Lazarus have bigs problems with Bitmap management. Not FCL directly, but i'm think it was not a good choice to manage color as 64 bit (TFPColor) by default. FCL-Image is not enough optimized, error management is not good, many bug are present between and with LCL RawImage/TBitmap.
I don't agree. The FPC/Lazarus graphics units are more general than yours. Your gif viewer can only display gif images. The TImage of the LCL, on the other hand, can display any graphics format if it is registered. And FPC-Image can work with images even without the LCL. It took me quite some time until I understood this. In addition FCL-Image is rather difficult to use, and it is easy to make mistakes - therefore, it appears to be buggy. It is not, at least not more than any other software. Using FPC-Image it is possible to paint a transparent GIF for sure - transparent png is working too (all the icons of the IDE are transparent pngs). But of course, if you feel better with your fastbitmap - no problem.
You can test, you'll see with FPC's many many GIF in the Imagetestsuite cannot be read correctly with FCL-Image.
Which ImageTestSuite do you mean? I guess FPC's GIF reader does not support all features defined in the specification. The same with other formats. But usually the most important features are supported (in case of GIF, of course, except for animation).
I think the teams should focus on all these small details and small persistent bugs from version to version, for giving more something more stable, especially to be able to cross compile properly without having to shield the code of {$ IFDEF} on basic things (I think of the TListView for example, or like here with the use of TLazIntfImage under Linux), rather than wanting to look like Delphi.
I don't understand what you want to say here. As far as I know the graphics formats are not on the focus of the current development. But they are certainly maintained. So, if you find a bug please report it to bugtracker and somebody will take care of it. Also, if you find some pieces of your gif code which could be merged into the code of fpreadgif you should submit it to bugtracker.
- Typeshelpers (large overlap with type-helpers built into fpc now)
I've included it because one of tester. Use an old version of lazarus but can be easly remove by replacing "ToString" by "IntToStr" instead, or move to the gifview demo 's folder
What would have been the problem to call "IntToStr" instead of "ToString" and adding an entire unit for it? In all the packages that I am maintaining I try to be as conservative as possible and avoid all new features in order to be able to allow old Lazarus and fpc versions.