Leaderboard

Check out

I can't say that I disagree wrt the localization tools. I only wish they would have admitted that they were completely broken (apparently beyond repair) 20 years ago, and deprecated it then, so we didn't have to waste time on that dead end. That said, while the ITE/ETM tools never worked, the RTL part of the localization system (i.e. resourcestrings, resource modules, etc) has always worked very well IMO. With regard to gettext/PO-files I've never had much success with it because it basically just translates phrases without regard for context. There are functions in gettext to translate with context, but the context has to be specified explicitly in code. https://www.gnu.org/software/gettext/manual/html_node/Contexts.html

A class declaration doesn't allocate any memory unless there are class variables inside that class. Memory is allocated when - at run time - the constructor is called. A variable having a type equal to a class is actually a pointer to the memory allocated for the class instance by calling the constructor. Class are handled "by reference". By the way, you should by a good book about Delphi programming (the language, not the runtime libraries). Look there to make your choice: https://delphi-books.com/en/

That is worrying. Remove a feature without offering a replacement. Somehow Embarcadero couldn't manage to create a stable and usable translation tool all these years? Even more worrying. While one determined man can create a decent tool as shown here. Did I say it is worrying? Then again, we can't even assign shortcuts to external tools. We can't hilite all occurrences of the selected word. We.. o enough ramblings already. Anyway, one industry standard seems to be GetText po files. IDE integration would be nice. Ha...

I'm afraid the integrated localization tools has been officially deprecated. Unfortunately the documentation still hasn't been updated to reflect this fact. https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Release_Notes#Translation_Tools So your best option is to use one of the many alternatives available. There exist both commercial and freeware solutions. I'm the author of one of the freeware solutions (the one linked to by Darian above) so I'll leave it to others to list the pros and cons of the different alternatives.

Back when Delphi was owned by Borland, they had a fairly generous policy towards handing out free copies of their software products. Their actual "Cost of Goods" was tangible since back then sofware came on disks and there were always books included in the boxes. (Delphi itself was given out free to everybody who attended the launch event in 1995. I was there! And lots of free stuff was handed out at all sorts of conferences throughout the 90's. But those things have faded out, along with User Groups and similar in-person events. I did do a local in-person event as an MVP a few years ago, and they refused to give me a free license to raffle off. But they did send a bunch of pens and note-pads -- at far greater actual expense than a license code sent via email.) Today you have to pay to get a DVD if you want a physical copy on disk. The COGs is ZERO. Yet Embt fails to see the value in giving away licenses for any number of valid reasons that used to be commonplace. Even MVPs only get a license that's valid for 365 days. Even though the COGs for Delphi are ZERO, they build-in a 4% automatic increase in the maintenance agreement every year. When was the last time anybody here got even close to a 4% raise from their current employer? I don't think I've EVER gotten a raise over 2.5% without changing jobs. Honestly, I may be done upgrading Delphi. I let my maintenance agreement lapse just before D11 was released and I'm not missing it a bit. The whole world is moving towards web-based products and the only thing in D11 of any consequence is support for Microsoft's new Windows update -- because I suspect most of the revenues for Delphi come from thousands of corporations who are beholden to Microsoft and will all be upgrading (whether they like it or not) over the next 6 months or so. This creates a lot of maintenance work, which seems to be the only thing anybody hires Delphi people for today. Nobody is building web stuff using Delphi. Most companies are moving towards a "mobile-first" approach to apps, and even that is being dominated by Microsoft in many shops. Which means C# and .NET. Hobbiests are not buying Delphi for its cross-platform benefits because all the tools and libraries needed have FOSS licenses. But TMS has this thing called WebCore and you can build web apps in Delphi with it. In fact, you can even use Visual Studio Code, which is free, instead of the Dephi IDE. They just made all of their FNC components so you can add them to VSC, quadrupling the number of components available for WebCore apps. And they're preparing an update to their "wrapper" technology (Miletus) that's like Electron and lets you take a web app and turn it into a native app. The next version will support more platforms than Delphi, including Raspberry Pi's. I have an ALL-ACCESS license from TMS and the annual cost to renew it is less than half of my Delphi Enterprise license. It doesn't automatically increase by 4% annually, and it buys me a collection of tools that offer far more flexibility and relevance in today's market. They're also not afraid to add valueable things to the language that WebCore supports (Object Pascal) that people have been asking for in Delphi for ages. They're constantly adding more and more cool things to their platform; it's enough to make your head spin. Meanwhile, this latest Delphi release had nothing new that I need in it. It doesn't even fix the Refactoring bugs introduced in the last couple of 10.4 releases. They still charged 4% more for it again; but to me, it failed to deliver even 4% more value over 10.4.2. If I look at what has happened with Delphi over the past 12 months, and at what WebCore has done, there's no comparison. WebCore is moving faster in directions that the market is embracing, while Delphi is simply providing support for the latest version of Windows, hoping to justify its existence for Corporate IT Depts who need to decide whether to write a check to keep the maintenance releases coming or not while all of their new development is being done with other tools. And here we are debating on whether this huge billion-dollar corporation can afford to give a comp license (that doesn't cost them a penny) to a guy who has contributed more value to the Delphi community than most of the new features and bugs they ship with every update they put out. Same debate, different year. I think the problem is that most Corporations are very slow to move new Delphi releases into production, so they don't miss delays in updates for big component libs and things like what Andreus does because they do make it out sooner or later anyway. I think Embt is really only interested in Corporations because they just keep renewing their licenses and don't do much otherwise. They don't care about language features, only whether it supports the latest Microsoft Windows needs.

Unfortunately there are two problems with dxgettext: Maintenance is basically nonexistent (apart from the odd fix I apply and my time is very limited). The original maintainer Lars B. Dybdahl hasn't committed any changes for years (the last log entry that from somebody else but me was in 2014) It only works for Windows, and there probably only for 32 bit VCL (I haven't tested 64 bit or FMX, but since it installs some hooks, it's unlikely to work without changes.) Regarding PoEdit: I prefer using Lars' tool "Gorm" nowadays, but that's because I have the source code. 😉

I'm using dxgettext for at least 10 years, and I can say "IT WORKS" but you have to manage many things... I've never tried other ways, however... and this is my limit. Any languages have its rules for plurals, and the same term could change meanings depending on the place where it is used. You have to spend a lot of time creating simple but clear initial English texts. https://youtu.be/Ac3xV1X7uzE For dxgettext you can use PoEdit editor which helps a lot for initial translations using Google or MS online translations servicies.

While I agree on having the new Indy sources in the repo as svn:external/submodule, I think leaving the original library in the search path (or even on the hard disk) may be dangerous. I have spent countless hours hunting for bugs that eventually turned out where caused by compiling the wrong sources / linking the wrong dcus. This can't happen if you delete them.

what happen at runtime when we are declaring some Objects ? i mean exactly this Declaration : vObj_Instance: TClass_Type; does this Allocate something in Memory ? or system resources .... No it does not I think you want a reference. Here is example where several forms have created and they may have Comboboxes in them. We use screen to find the forms and component list to find a combobox for the demo. procedure TEventBoss.showComboBoxDropDowns; var I,C: integer; F: TForm; //Ctrl: TControl; //hint need learn about the child lists in here plus Parent prop!// ComboBox: TcomboBox; begin with Screen do begin // access the applications forms here for I := 0 to formCount - 1 do begin F := Forms; // point F to form instance for C := 0 to F.ComponentCount - 1 do if F.Components[C] is TCombobox then begin ComboBox := F.Components[C] as TcomboBox; F.Show; F.BringToFront; ComboBox.Show; The 'found' combo box instance is told to show //how? The ref has its address.// sleep(1200); caption := F.Name; ComboBox.Perform(CB_ShowdropDown,1,0); sleep(1200); ComboBox.Perform(CB_ShowdropDown,0,0); break; end; end; end; end;

While using default phrases as keys looks nice at 1st glance, such nuances just kill all benefits of this approach IMHO. Not talking about a case of key phrase modification. I prefer another approach when each phrase has its artificial code. This one is used in all Android apps so does pretty well.

As I said, a variable having a type equal to a class use NO MEMORY until it is assigned a value coming from the constructor (A constructor use dynamic memory allocation to create space for the object instance and return the pointer). If you copy another variable value, then you have a second pointer pointing to the same object instance. beware of pointer becoming invalid as soon as the object pointed to is destroyed.

Don't ever call NewInstance - this s internal method. https://docwiki.embarcadero.com/Libraries/Sydney/en/System.TObject.NewInstance You should call constructor to create (allocate) new object. vRef := TBaseForm(AFormClass.Create(aOwner)); or you can typecast with as operator which will fail at runtime if the AFormClass is not TBaseForm vRef := AFormClass.Create(aOwner) as TBaseForm; When you declare variable var vRef: TBaseForm; This will only automatically allocate pointer (reference) to your future form - if this is local variable it will be allocated on the stack, if it is field it will be allocated as part of object instance. This is automatic and you don't need to manage memory for that pointer, variable itself. Only when you call constructor actual object instance will be created and allocated - if you create form with owner, that owner will be responsible for releasing its memory. If you pass nil for owner, you need to release it yourself. There is no class instance here, only object instances. Class instance is constructed when you declare class variables in class declaration - and they are automatically allocated and deallocated and there is only single one per class. Again you are not using them in your code. Following is example of class variable declaration. Variable Foo is accessible as TBaseForm.Foo or as vRef.Foo but it will be the same shared integer variable. TBaseForm = class(TForm) public class var Foo: Integer; end;

Well... intf procedure DoXPlatformStuff impl procedure DoXPlatformStuff {$ifdef windows} do lots of Windows stuff {$endif} {$ifdef lunix} do lots of Linux stuff {$endif} {$ifdef macos} do lots of MacOS stuff {$endif} ... repeat for all 100 platforms FPC supports and do it for EVERY platform-specific function Compare with includes: intf procedure DoXPlatformStuff impl {$ifdef windows} {$I 'dowindows.inc'} {$endif} {$ifdef lunix} {$I 'dolinux.inc'} {$endif} {$ifdef macos} {$I 'domacos.inc'} {$endif} ... repeat for all 100 platforms FPC supports

well, you seem more familiar with what Pascal offered, before Dephi introduced 'class' types. And I don't know what to say about the question regarding EXEs. That's totally unrelated to storage allocation of classes. Or I'm not understanding your question. See if you can snag a copy of Marco's book (ask Google) and work your way through it. That will get you onto very solid ground.

Although the multi-platform approach never appealed to me, it still sounds terribly interesting. Do you have a reading recommendation (a presentation video is fine too) that explains their general approach?

If you have a Delphi license, you can get the latest version of Marco's book from the portal. Maybe it's available elsewhere for free as well. you can also get it from Amazon Kindle here: https://amzn.to/3iuvbTf

What languages are you most familiar with? You seem to have certain ways you're thinking that are not applicable to Delphi, so it would be helpful to know where you're coming from.

What FPiette said above ^^^^^^^^^^^^^ is accurate, if not a bit brief. What you're thinking is how RECORD types work. They act like STRUCTs in C/C++. In the last version of Turbo Pascal, an 'object' type was introduced that was like a class (with both data and method members) that behaved like a record (static memory allocation). When Delphi was introduced, it deprecated 'object' types and added a 'class' type where everything was implicitly derived from a base class called TObject, and variables declared as type 'class' are references (pointers) to dynamic objects on the heap. Unlike regular Pascal pointers that need to be dereferenced with the '^' operator, references to class instances are implicitly dereferenced and allow you to just use the '.' operator to access members. That's one reason why you can see the same code expressed in Delphi and C++ and the C++ code looks horrendously more complicated. (The C++ is closer to what you'd see in Delphi using records or deprecated 'object' types.) There's a free book that Marco published via EMBT that is a great introduction to Delphi. It'll take you step-by-step through all of this stuff. BTW, RECORD types in Delphi have evolved to the point where they're very similar to classes today, but they still retain their static memory aspect when you declare instances of them. Record instances are 'value-based' whereas class instances are 'reference-based'.

It's all find and dandy to come up with all sorts of ideas that we as developers would love to see. But I believe that the reality is that most of the revenues come from corporations who are mostly interested in risk-reduction, not more usable software. I don't believe that EMBT is making most of their revenues from Delphi products because they're being actively used for new product development. Rather, I believe it's coming from corporations that built large apps between 2000 and 2010, and those apps are still producing strong revenues with modest investment in maintenance. These customers have been just running things as-is for the past 10-15 years, and they invest in minor updates to keep them operational. I believe the latest language enhancements are ignored, as are most of the new features. These customers simply keep renewing the maintenance agreements because it's the least-cost thing to do that minimizes their risks in case something unexpected happens. As one of the devs at a place I worked in 2009 liked to say, "We're all here just keeping a comatose patient alive long enough for them to migrate this project over to .NET." During the short time I was there, they missed the first two major milestones for that migration, and the schedule got pushed out by an additional year. The company was REALLY upset when Microsoft announced they were end-of-lifing Windows XP. I mean, these guys were so paranoid of changes to Delphi's math libs that they spent months running a HUGE bunch of regression tests on every new Delphi release looking for deviations in calculations less than 10^-6. Newer releases past D6 failed, and with MS abandoning XP meant it could cost them billions of dollars due to even the tiniest deviations in math calculations. I tried to move them to D2010, but one of their devs built some components that would make most folks here faint due to their total non-conformance with component building guidelines, and they wouldn't build properly under D2010. That's not to say there isn't new development and even innovation going on with Delphi in shops around the world. But it explains why the language itself is at least 10 years behind most contemporary languages; why the most urgent updates to the platform actually track updates that Microsoft, and now Apple, make in their latest hardware and/or software releases; why the run-time technology (like high-DPI stuff) hasn't gotten much attention (because most applications are running on machines barely capable of displaying full HD resolution); and why nothing reflects much concern for anything other than Microsoft, Windows, and making the run-time libs more similar to C# libraries than anything else (IMHO). ********************** If you want to see REAL INNOVATION in this space, take a look at what TMS Software is doing. They've created a more intentional and cohesive extension of the Delphi platform in the past 18 months than EMBT has done since they bought the company from CodeGear. I can't say for sure, but I suspect a larger percentage of their revenues come from developers who have a larger say in their future wants, needs, and desires than your average IT Manager or CIO. They're actually intersted in things that are not tied to Microsoft or Apple and extend into a more homogeneous cross-platform ecosystem that has web development in the center of everything. They are solving difficult multi-platform problems that EMBT should have been working on for 5+ years now if they really cared. And they are not waiting for EMBT to address any of the shortcomings they may encounter. One of their key players, Dr. Holger Flick, has written and published three (3) new books in the past 18 months, with more coming! With TMS tools, you don't even need Delphi to build Delphi apps that run in more platforms than EMBT supports TODAY! (See the screen-shot below) You can build them in Visual Studio Code, and using Lazarus you can even build executables that run natively on Linux machines without having to spend thousands of dollars on an "Enterprise Edition" Delphi license. We don't need more threads trying to lay out a direction that EMBT can take to make Delphi nicer for Developers, because Developers are clearly not EMBT's target market. (I don't know about you, but in the past 15 years, I've been the only person every place I've worked who had my own personal Delphi license to ensure I could keep up with new developments. That's because the production code at most places was a few releases behind the latest Delphi release.) Get invovled with TMS products and see if there's something there worth focusing on. Not their older VCL, FMX, and Intraweb (gawd, is that still around?) libs, but the newer WebCore, FNC, and Business Suite stuff. Their next release of WebCore will let you create web apps that run natively in more platforms than Delphi supports, including Raspberry Pi -- without requiring you to have access to a compiler that generates ARM code. And you won't need to have your dev machine tethered to another dev environment to do cross-compiles. (I know this is going to raise some hackles, so ... I say it's "native" because there's a wrapper that runs as a native app and it allows the code encapsulated inside of it to run within a web browser. There's no hardware that runs javascript in the same way there's nothing that runs java bytecode.) The photo below is a snapshot from a video they posted recently illustrating support for the Raspberry Pi. that shows the platforms WebCore will support in its next release (which will probably be out before EMBT releases their first "bug-fix" update for D11) using either Delphi or VSC as your dev platform. Their strategy does NOT depend on what Microsoft or Apple may or may not do, or what the next release of .NET or iOS might provide. WebCore targets javascript running in the web browser, which is becoming more universal than Windows. I invite all Delphi developers to stop complaining about what EMBT is NOT doing and start cheering on and supporting these guys who are actually INNOVATING around the Delphi language and EXPANDING the Dephi ecosystem -- RAPIDLY! (Buffalo Springfield's song, "For What It's Worth" is echoing in my head...)

Before starting a new thread about the "future of Delphi", please give some more context what exactly you would change. It would be helpful for a discussion to summarize the content of presentation and to adopt it to Delphi. There have been several threads about the "future of Delphi" and actually I am not sure, why this thread should be different or bring in any new aspects. Of course everyone of you is free to create a new thread - but you should take a moment to check, if it's really a value for the community of if it's just a recapitulation of existing threads.

The title of the issue you lodged, and the question itself seemed to indicate that you did not have a version for Delphi 11 Alexandria. Perhaps I should have asked whether or not you could compile. I guess your answer means that you can. Given that, is the issue resolved?

i have god experiance with the follow product https://korzh.com/localizer

I think David was staying on topic?

Seriously, wtf...