Jump to content
Kuuzu Forum

All Activity

This stream auto-updates     

  1. Past hour
  2. raiwa

    What the software should be

    @piernas , it was just an example, even "recoger" may not be problematic, a latin american user translated "store pickup" with "levantar en tienda", so there is just a difference of usual expressions, which make potiential local buyers feel more comfortable. And of course, there are many, many other language localizations which will have many more examples like this.
  3. Today
  4. clustersolutions

    Software Lessons Learned #1

    It's just because it was no longer a binary problem (0, 1, false). I always check the doc if I can't remember what a function returns. At the same time, I had brushed off the "false" for preg_match once I would do a snippet test and be able to be confidence that it was bounded to a binary outcome. Then I would ask myself do I need to confirm the type. The mb_string thingy is a better solution, but I would still parse it 5000 strings at a time as the function has a potential to parse huge files. It kinda reminds me of Oracle's internal, probably MySQL now, too. It would do a check on an SQL's length and its first and last number of words, and if they are the same, it would then proceed to reuse an execution plan instead of re-parse the entire SQL. It made a name for its performance.
  5. MrPhil

    Welcome!

    This means different things to different people. I don't think it means that we have to sit down with a blank sheet of paper and reinvent everything. We can certainly borrow ideas, algorithms, and even lots of code from existing projects (e.g., osC 2.4), without having to maintain any compatibility with that implementation. Is that the intent?
  6. MrPhil

    What the software should be

    Arrgh. The allowed edit time is too short. Frank? Add: We still need to think about additional definitions needed for add-ons and other extensions. They are likely to be in English, but lag far behind in getting translated. Perhaps an English default or fallback should be part of any add-on, to be overridden by a translated pack later? That still leaves the issue of whether, say, Argentine Spanish is going to be one monolithic language pack with all add-ons, or an admin is responsible for pulling in a translation file for each add-on that site uses. That should probably be automated in some manner, so that a site always has the desired languages at the proper version for its add-ons.
  7. MrPhil

    What the software should be

    Just because code and comments are written in English doesn't make English somehow "core". Neither the owner/administrator nor the customer will see MI_HEADER_THING, just whatever the define translates into for their selected language. The administrator selects one or more language packs to install and be available. US English could be the default, but it doesn't necessarily have to be installed (depending on how language support is structured, it might be a fallback for missing definitions in other language packs). When running the site, an available language is selected (first, querying the browser; second, logged-in user or admin has a stored preference; third, anyone can select another installed language from a menu).
  8. Antonio García

    Software Lessons Learned #1

    It seems that it's NOT a good idea that a function returns FALSE (in most cases). At least a few of people explain why it's not a good idea... http://codeinthehole.com/tips/return-false-with-prudence/ https://www.brandonsavage.net/always-return-something/ I find this kind of opinions when I started learning a little (a very little) about Domain-Driven Design in PHP...
  9. Antonio García

    Software Lessons Learned #1

    @Kymation and the rest. May ask here something about how 2.4 interprets or use 'classes' or is better create "Software Lessons Learned #2" ?
  10. Antonio García

    What the software should be

    ¡Pues si! I mean, yes. I agree with both of you (I though the same, in our 'ideal' soft). If one that speak Balochi download kz then, as ubuntu (windows, etc) does, in the first few window's installation he will be asked for their default language. He will be able to choose the ones that the comunity (led by the languagekeepers) provides (English -the default, Spanish, German, French...). If you are from Equatorial Guinea may be you will download Spanish and French (both 'official' languages, supervised for people from here). In admin you will be able to choose the languages to download from K, as a app. But our customers speak Balochi (my no comprender), so the screen ask if you can create a new language. He are asked for registration and then he goes to a kind of long form where he will start to translate 'No' to 'oN', etc. The form (or kz in some place) ask to customer if he want to collaborate in the translation packs (with a link explaining a lot of beautiful things). If he says 'Yes' (or in Balochi 'seY'), then their changes will go to k.org inserted in our beautiful language database. Next time, the Balochinean will be finded as 'unnoficial language pack'. May be not complete, with only ONE person collaborating... but the process continue. May be the 'Spanish council' agree that 'OK' need to be translated in spanish with 'De acuerdo', but may be a lot of others think that 'Me parece macanudo' is a best translation. So here is the place where the 'community language responsable of the Spanish' will manage/decide if change the translation or not. May be this kind of procedures comes from the same big form when one change a particular term...
  11. burt

    Software Lessons Learned #1

    If this cart wants to be something, all these old style functions written in php4 times need to be re-coded to a modern standard. Put simply: osCommerce is 18 years old and much of the code written then...is still in there now.
  12. JcMagpie

    Welcome!

    Hi Frank, Happy to help in anyway I can. I’m not a developer or coder but I do run businesses that operates several e stores so my approach will be from the end user prospective. I have already posted my views on the main forum but for clarity I’ll list them here again. For me as a user, 1) Clean start with no legacy issues. 2) Totally modular design 3) Core code is made closed (no messing with it) use addons 4) Review how we make it responsive (bootstrap or alternative?) bootstrap works but is not the only option. 5) Totally integrated modification function. As and when updates to the core are made by the team they are pushed out and available in admin. User simply presses install and core is updated. (already available in opencart) 6) Totally integrated addon function. Same as 5 above but for addons. Both paid and free ( should consider the option of approved free addons and none approved) ( already available in opencart) Quality control will give a much better experience to the end user. 7) Store side editing function. A simple way to let you make changes to the store front with out needing to edit files. Data import capability. The only way to make it successful is if we make it easy for people to move to it from another osC versions or other carts. As has already been mentioned every new project starts with good intentions, the challenge will be to stick to them. Many have attempted similar projects before and make the mistake of becoming another “me to” product as its the quick and easy option. We will need to offer something unique if we are to stand any chance of gaining traction in a very crowded market. In my opinion and “please do not take offense as none is intended” the mistake made by many of these “me to” carts is they just copy the previous “in trend” cart and add one or too extras features! We need to start with the customer and only the customer as the main focus. The code is very important but its of no use to anyone without customers. I am sure we could produce beautiful tight super efficient code. The customer will never know this and many don't care as they will never see it. The only thing the customer will care about is what he sees when he installs and what the cart allows him to do. Its this out of the box experience that should be a key target for the project. A quick example from my recent experience as I have just updated all by stores. I looked at several alternatives. One stood out from all the others, this was open cart. As an out of box experience it won hands down. Why? It just looked very professional straight out of the box. Let me know what required and if I can help I will. Help with funding in not out of the question just need to see a bit more meat on these fresh new bones. Zahid
  13. OSCOMMARKET

    Software Lessons Learned #1

    Collection from SO Q&A's Merged into one function: public static function isUTF8($string) { if (preg_match('!!u', $string)) { // this is utf-8 return true; }else{ // definitely not utf-8 //do something like: iconv(mb_detect_encoding($string, mb_detect_order(), true), "UTF-8", $string); } }
  14. OSCOMMARKET

    What the software should be

    One more thing for languages. This is pretty important for the search engines. I hope we all learned by now: www.mywebsite.com/index.php?language=english is UNWANTED. Default (browser detection) site flow should stay as is. But when switch from english to Spanish via the language selection url's should not change. The parameter index.php?cPath=1_2&language=XXXX must be taken out. To better explain i post an old link to an article from the net: https://searchengineland.com/the-ultimate-guide-to-multilingual-and-multiregional-seo-157838 Especially if scroll or arrive at the following heading: The X-Default Hreflang Attribute Value: <link rel=”alternate” href=”http://example.com/en-gb” hreflang=”en-gb” /> <link rel=”alternate” href=”http://example.com/en-us” hreflang=”en-us” /> <link rel=”alternate” href=”http://example.com/en-au” hreflang=”en-au” /> <link rel=”alternate” href=”http://example.com/” hreflang=”x-default” /> Above, http://example.com would be the default page for users outside of Great Britain, the United States or Australia.
  15. OSCOMMARKET

    What the software should be

    One other pretty important thing that needs to be sort out for languages is the database multi-language capability. Products names and descriptions ar db driven., same for categories. When there is installed later on a new language to the system, that language will not hold any data for that new installed language. Correct me if i am wrong, currently osc falls back to the default language if that occurs. Yet.... for add-ons this is not the case. Kuuzu should cover that also. The system must be able to "detect" when install a new language, and db languages are required, it handle these also.
  16. OSCOMMARKET

    What the software should be

    @frankl yes, that was the initial plan. But there must be kept in mind, as that part is only for the core and after some time all languages will be available. It does not mean that will also be the case for add-ons. Yet, EXACT same process should be available for ANY App that will be released. When install an App, the same process for it should be available, as when you first time installed Kuuzu. If there is no supported language available for the App based on the language of your system. The App falls back to the initial provided language. That can lead to something like this: System uses Spanish and German. App is written in English. Checking "languages server" No additional languages for the app are available.(Makes sense if it is an app that is just newly released). The APP will now use the English translations for Spanish and German system languages. The System owner can now translate each text by himself via de Admin->Language editor. Cool functionality from the system would be if can pass these translations automatically over the the language server. Others can re-visit these translations: Henry's translations: 1.0.0 1.0.1 (Frank revisited it) 1.2.0 (Frank,Dan,Garcia,cluster revisited). Pablo (real spanish guy) not like what the others have done: Pablo makes a : 2.0.0 All the other kuuzu users like pablo's version most. So it becomes default. More installations of the App will follow. Spanish is available now for it. First in the list will be Pablo's translation. Comprendé?
  17. Kymation

    Software Lessons Learned #1

    I think that this code was intended to deal with language files that could be provided by third parties in some unknown encoding. The core Language class seems to have the capability of detecting an incorrect encoding and converting it to UTF-8. Of course this process will never be perfect, but we should at least try to not introduce additional sources of error. Regards Jim
  18. clustersolutions

    Software Lessons Learned #1

    Perhaps it was because using packages outside of the default install was a consideration... identity type checking, i think that's what it's call, could be difficult especially when dealing with legacy codes. it could be a can of worms and i always try to be very sure before using it. at one point way back a school of thoughts was to build all logic in the backend. i mean, how often do we do look into the type in the backend before writing our middle tier code? i try to especially when i know it could be critical to the app... php...it is what it is...
  19. frankl

    What the software should be

    Installation routine should be multilingual - as many languages as necessary. One solution: At installation select what languages you want in your store. Kuuzu fetches those languages from the Kuuzu server during installation and installs them (or just default english). Later add or remove languages, Kuuzu will either grab them from the server or delete them. That way translations are kept up to date in one central location.
  20. Kymation

    Software Lessons Learned #1

    It should return what the comment header says it does: either true or false. Or change the comment if you want it to return something else. It's the mismatch between the documentation and the code that's dangerous. It should also throw an error if there is an error condition. Errors are extremely important if you're trying to debug something. Regards Jim
  21. frankl

    Software Lessons Learned #1

    I get your point about what this function returns. Should be either 0 or 1, or true or false.
  22. Kymation

    Software Lessons Learned #1

    We're probably going to continue to use UTF-8, so I'd say that the Multibyte functions are going to be essential in any case. Might as well make use of them. Regards Jim
  23. Yesterday
  24. clustersolutions

    Software Lessons Learned #1

    I was gonna say...but if performance is still a concern replacing preg_match with mb_detect_encoding is a good way to go. Also, mb_detect_encoding I believe requires additional package to be installed. Good stuffs...
  25. Kymation

    Software Lessons Learned #1

    One additional point that I didn't think of when writing the above: That regexp was written in the days of PHP 4, when servers and PHP itself were notoriously slow. Optimizations like this were common when you needed to make the code as fast as possible for it to be usable. Since then, servers have gotten faster and PHP has seen massive speed improvements. PHP 7 is noticeably a lot faster than even 5.6. Given these improvements, you would need strong justification to use this complex code in place of a simple PHP function. Regards Jim
  26. I've been looking through some of the code that we might base Kuuzu on. This is not decided yet (at the time I write this) so take this as a generic example of what might be. This will probably be of interest to those who already know some PHP and want to know more. I'll try to not be too technical, but it may get a bit deep in here. Feel free to ask questions in a post in this thread, but please try to keep it on topic. Some of this will also involve my opinions, which I have collected over more than 40 years in the business. Feel free to disagree in your post, but please support your opinion with facts where possible. We're all here to learn. The code is from the Language class in osCommerce 3.0.2. I'm going to focus on one method in this class, mostly because it illustrates some important points. So here's what I am talking about: /** * Detect if a string is UTF-8 * * @param string $string The string to detect * @return boolean * @since v3.0.2 */ public static function isUTF8($string) { if ( strlen($string) > 5000 ) { for ( $i=0, $s=5000, $j = ceil(strlen($string)/5000); $i < $j; $i++, $s += 5000 ) { if ( static::isUTF8(substr($string, $s, 5000)) ) { return true; } } return false; } else { return preg_match('%^(?:[\x09\x0A\x0D\x20-\x7E] # ASCII | [\xC2-\xDF][\x80-\xBF] # non-overlong 2-byte | \xE0[\xA0-\xBF][\x80-\xBF] # excluding overlongs | [\xE1-\xEC\xEE\xEF][\x80-\xBF]{2} # straight 3-byte | \xED[\x80-\x9F][\x80-\xBF] # excluding surrogates | \xF0[\x90-\xBF][\x80-\xBF]{2} # planes 1-3 | [\xF1-\xF3][\x80-\xBF]{3} # planes 4-15 | \xF4[\x80-\x8F][\x80-\xBF]{2} # plane 16 )*$%xs', $string); } } At first glance this looks like nice, clean modern code. It's even commented (A rarity for those of you who are used to osCommerce code). So let's dig in. The comment block at the top is in PHPDoc format. It tells us what this method is for and what the inputs and outputs are. It also states when this was added to the codebase, which is useful if we're looking at some older code. The method itself is here to detect whether the characters in a string are in the UTF-8 character encoding or some other encoding (Probably ISO 8859-1). This is useful for checking language files and language-dependent database entries. So far so good. The method itself is declared as public and static. That means that we can use it anywhere in the application, and that it doesn't need to be initialized first. Since the string is not going to change during a request, there's nothing wrong here. The first section of the method, which starts with the first if() statement and ends with the else clause, deals with strings that are too long to parse. Any string over 5000 characters long is broken up into 5000 character segments. Why 5000? Is this some buffer size, a language restraint, or just arbitrary? There's no way to tell. The programmer should have documented this decision in a comment, but they didn't. It's probably not critical, but if we start having problems with this part of the code, it would be nice to know if this is a likely point of failure. Anyway, this section passes a chunk of 5000 characters back to itself. This is known as recursion. It's a bit expensive in terms of memory and processing power, so it's not my favorite thing in PHP, but I don't see it as much of a problem here. Depending on the result that is returned, the method may return a true, or it may continue checking segments until it finds a true answer. If it does not find a match in any of the segments it will return a false. There's actually a problem with this, but it's in the next section, so I'll save it for later. The next section is much more interesting, as it contains a complex Perl Regular Expression (regexp) that tries to match characters in the string that was passed to it with characters that would be expected to occur in a UTF-8 string. This is a massive and obscure regexp that is time-consuming to parse and debug. Usually complex matches like this are tested in sections and only assembled into the whole thing when each section passes the test. It is commented with what each section is supposed to match, so that testing is at least possible. This code would still need a fair amount of testing to be certain that it is working properly. Now here's where it all starts to go pear-shaped. The comparison is done by the preg_match() PHP function, which returns the following: A 1 (one) if a match is found. A 0 (zero) if a match is not found. False if an error occurs. This method returns the result of the PHP function directly, which means that the method is actually returning either 1, 0, or false, and not the true or false that was promised by the description. Fail! Well, not entirely. PHP will helpfully cast a 1 as true and a 0 as false if you let it. If we look at another line in this class that uses this method, we find: if ( !static::isUTF8($string) ) { Yes, it's implicitly casting a 0 as false. Of course an error will also return a false, so we have no way of knowing if an error occurred in this method. This is very bad programming practice, as it makes debugging much more difficult. This method needs, at the very least, some code to detect the output and properly convert a 1 to true and a 0 to false, and to throw an error if it gets an actual error response. If I naively were to use this method in my code, after reading the description and not closely examining the code, I would probably write if ( static::isUTF8($string) === true ) { This is an explicit test, and the right way to make sure that everything is working as it should. Of course it isn't: this test will fail on any string less than 5000 characters long, as the method will return 1, 0, or false, but never true. However it will work properly if the string is more than 5000 characters long, as that first section will properly return a true or a false. This is a debugging nightmare. Massive Fail! So we need to add some code to make this work properly. Or is there better solution? Those of you who know PHP extremely well, or know how to use Google a search engine, will probably suggest the mb_detect_encoding() PHP function. All I need to do is $result = mb_detect_encoding($str, 'UTF-8', true); if ($result === true) { and I can avoid all of that complexity. So why not? Again, the programmer has dumped this whole mess on us without any guidance. A comment giving a brief reason for doing this would be helpful, but we are left guessing. Or, as above (*cough* search engine *cough*), we can find this regexp in a comment on the PHP manual entry for mb_detect_encoding(). Apparently it's faster at the expense of some precision. Unfortunately the implementation here is also buggy and a probable case of code bloat. We would need to decide whether the perceived speed increase is worth the reduced precision and extra code used here. My impression is that it is not. However, I have spent way too much time testing software like this for errors like this, so I'm definitely biased in favor of keeping the codebase as small as possible. So, some lessons (hopefully) learned: Document everything. If you make a decision, no matter how obvious you think it is, write it down. Don't take shortcuts. PHP may do things like casting numbers to booleans, but don't do it. Coding standards need to prohibit shortcuts. I hope I've shown why. Think about testing. If there's a possible error condition, make sure it returns an error and doesn't get buried as a legitimate result. The person who has to debug this may be you, and you may have forgotten ever writing it. Give yourself a break. Comments/criticisms/suggestions welcome. Regards Jim
  27. OSCOMMARKET

    What the software should be

    @Antonio García This can be done very *easily. IT IS SIMPLE I will not try to find Gergely's solution/proposal in the moment (if i am able to edit my posts i will put a link to it later on). EACH add-on proposed the "market", each language file can be submitted to the (not yet available link) *link. There..... translations can be made by "community" members, who support THAT specific add-on. Based by rating, end-user get a proposal to use the translation by choice. Yes the system not provide these options YET, to allow YOU to choose what "language-repository" you are going to use. Further............... What if you change your mind....................????????????????????????????????????????? I can not stop "reminding"............. it takes a hell of a work to serve you all!
  28. OSCOMMARKET

    What the software should be

    As i cannot edit my post......... Here we require a fall-back........... simply............ English. There is NO argument possible in this matter. Should be read as: Here we require a fall-back........... simply............ (DEFAULT LANGUAGE). There is NO argument possible in this matter.
  1. Load more activity
×