Thank you for the follow-up and the example with ossn_database_settings(). I appreciate you taking the time to demonstrate this.
You're absolutely right that ossn_database_settings() provides access to the database credentials - I should have tested this approach when you first suggested it. My apologies for not following up on that suggestion properly.
However, in the meantime I've implemented a different solution that works well for my use case: I'm using LibreTranslate (self-hosted in a Docker container) to handle the translation functionality. This approach offers me a few advantages:

Complete privacy control - no external API dependencies
No direct database queries needed for the translation feature itself
Easy to maintain and update independently from OSSN core

That said, your point about ossn_database_settings() is valuable information for the community, especially for developers who need direct database access in their components. It's good to know this function is available and I'll keep it in mind for future development needs.
Thanks again for your patience and for sharing this solution!

you can test it out https://nlsociaal.nl/test/home

even comments can be translated

As for your learning curve:
5 days ago I gave you the hint to use ossn_database_settings() in order to retrieve the credentials you need.
No idea why you haven't given it a try, but continue claiming "The config constants aren’t available through components" ?
Just add this line to the Hello World component - and check your error_log file: All credentials are available.

//this function is use to initilize ossn
function ossn_hello_world() {
  error_log('dbcredentials ' . ossn_dump(ossn_database_settings()));
  /**
  * Lets add our css to ossn default css file,

Aaaaarrgg
Okay good for my learning curve.

Eric, i think you misunderstood. Besides all the things PDO also not support multiple inserts in one statement. And it doesn't matter if its PDO or any other wrapper. Even if you paste mysql statements in example phpmyadmin it splits the queries, OSSN comes with ossn_run_sql_script to run bulk queries insert/updates/deletes

example

$script = "ALTER TABLE `ossn_object`ADD KEY `time_updated` (`time_updated`);
ALTER TABLE `ossn_annotations`ADD KEY `time_updated` (`time_updated`);
ALTER TABLE `ossn_users`ADD KEY `time_updated` (`time_updated`);";

ossn_run_sql_script($script);

The PDO / Database Access Story
During development I also needed bulk database writes, because tagging thousands of posts with a language flag one-by-one using OSSN’s entity system was painfully slow.
That led to the PDO question.
I assumed OSSN would expose credentials cleanly, but:
OssnDatabase->execute() doesn’t reliably handle bulk INSERTs
The config constants aren’t available through components
And requiring ossn.config.db.php didn’t expose constants either
So initially I could only make progress using hardcoded PDO, which obviously isn’t suitable for a distributable component.
So I asked essentially:
“What’s the proper, official way to get PDO access inside an OSSN component?”
Because what I really wanted was:
a direct PDO handle
without hardcoding credentials
without rebuilding OSSN’s database layer
without refactoring core files
This isn’t documented, so I needed to reverse-engineer how OSSN wraps its DB connection.
Final Result (In Plain English)
What I built is now:
A privacy-first language detection and translation module for OSSN that runs 100% locally, filters feeds by language, and uses the best possible technical compromises without violating OSSN’s architecture.
It achieves:
Local language detection (LibreTranslate)
Local translation (LibreTranslate)
GDPR-safe, no external calls
Language-aware feed filtering
Self-viewing posts always visible
Reasonable performance without core rewrites
Is it perfect?
No — especially if you compare it to Google/DeepL or full-text search engines.
But for a privacy-focused social network, this is honestly the best ethical and technical fit.
Users can:
read posts in their language
translate foreign posts
keep their data out of Big Tech systems
And that aligns with the entire vision behind JustBSocial.eu.

And also why normal user need to know that its PDO

Eric,
your credentials stuff looks pretty ugly.
Why don't you simply use the library function ossn_database_settings()
the same way as in the OssnDatabase::connect() method?

for the info.
Making an component that gives the user content(timeline post/groups etc) in there own langauge(not translate)
so user set his profile to PL, all content made in PL is displayed in PL

From user side the choice is only PL, or all!
so far so good, but it only works now with DB credentials in the component

if (!ossn_isAdminLoggedin()) {
return;
}

// ═══════════════════════════════════════════════════════════
// CREDENTIALS:
// ═══════════════════════════════════════════════════════════
$LFEED_HOST = 'localhost';
$LFEED_NAME = 'sql_nlsociaal_nl';
$LFEED_USER = 'sql_nlsociaal_nl';
$LFEED_PASS = ''; // ← FILL IN!
// ═══════════════════════════════════════════════════════════

$GLOBALS['LFEED_HOST'] = $LFEED_HOST;
$GLOBALS['LFEED_NAME'] = $LFEED_NAME;
$GLOBALS['LFEED_USER'] = $LFEED_USER;
$GLOBALS['LFEED_PASS'] = $LFEED_PASS;

all other option breaks the connection

Image

Great, trying this

Using phpMyadmin, you may run a query like

SELECT * FROM ossn_entities AS e JOIN ossn_entities_metadata AS em ON e.guid = em.guid WHERE e.type = 'user' and e.subtype = 'language'