aia Posted June 22 Share Posted June 22 In the language translation interface, we need a filter for language strings used in the frontend. This would be super useful for frontend translations on multilingual websites where we don't need localized ACP but have readers from different countries. It would also be great to have this information in exported XML so that it is available for external translation tools. Sonya* 1 Link to comment Share on other sites More sharing options...
Marc Stridgen Posted June 24 Share Posted June 24 Its worth noting there may well be strings used both in the ACP and on the front end Link to comment Share on other sites More sharing options...
aia Posted June 24 Author Share Posted June 24 7 hours ago, Marc Stridgen said: Its worth noting there may well be strings used both in the ACP and on the front end For my case, I only need a flag indicating 'Used in Frontend'. To accommodate all scenarios, you can consider marking strings with one or both of the following flags: 'Used In Frontend' and 'Used in ACP'. This allows flexibility depending on where the string is used. Marc Stridgen 1 Link to comment Share on other sites More sharing options...
teraßyte Posted June 24 Share Posted June 24 The problem is that all language strings are currently in the same IN_DEV lang.php file. There is no distinction on where they're used. At least in 4.x, no idea about v5. The developers would need to go through all language strings, manually change the file format flagging each string with admin/public (or both), and finally change how the file is parsed reworking the build process. And if you then use an admin-only or public-only language string in the other area, you'd have to remember to go back and update the flag or it would display wrong. IP.Board 3.x used to have separate admin/front language files, but that also caused issues because there were tons of duplicate strings since the files were only loaded in their respective areas. Which is why I assume they unified everything for 4.x. While the flag idea is a simple one, honestly I can't see an easy way to actually implement it. 🤷♂️ Link to comment Share on other sites More sharing options...
Daniel F Posted June 24 Share Posted June 24 Please keep also in mind that many strings from the backend are also used in the frontend by 3rd party devs, and let’s not get started about other locations like emails and the fact that we already have a separation between normal strings and strings used for JS output:) I get your point about the wish to separate these, but it’s really much easier and faster to maintain one base. teraßyte 1 Link to comment Share on other sites More sharing options...
Recommended Posts